This Page Is Inserted by IFW Operations 
and is not a part of the Official Record 



BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of 
. the original documents submitted by the applicant. 

Defects in the images may include (but are not limited to): 

• BLACK BORDERS 

• TEXT CUT OFF AT TOP, BOTTOM OR SIDES 

• FADED TEXT 

• ILLEGIBLE TEXT 

• SKEWED/SLANTED IMAGES 

• COLORED PHOTOS 

• BLACK OR VERY BLACK AND WHITE DARK PHOTOS 

• GRAY SCALE DOCUMENTS 



IMAGES ARE BEST AVAILABLE COPY. 

As rescanning documents will not correct images, 
please do not report the images to the 
Image Problem Mailbox. 



US006618389B 



en) United States Patent 

Hoefelmeyer et al. 



(io) Patent No.: US 6,618,389 B2 
(45) Date of Patent: Sep. 9, 2003 



(54) VALIDATION OF CALL PROCESSING 
NETWORK PERFORMANCE 

(75) Inventors: Ralph L. Hoefelmeyer, Colorado 
Springs, CO (US); Michael L. 
Hutchinson, Monument, CO (US) 

(73) Assignee: WorldCom, Inc., Clinton, MS (US) 

( * ) Notice: Subject to any disclaimer, the term of this 
patent is extended or adjusted under 35 
U.S.C. 154(b) by 0 days. 

(21) Appl. No.: 09/877,890 

(22) Filed: Jun. 8, 2001 

(65) Prior Publication Data 

US 2002/0172158 Al Nov. 21, 2002 

Related U.S. Application Data 

(63) Continuation-in-part of application No. 09/444,099, filed on 
Nov. 22, 1999, now Pat. No. 6,385,204. 

(51) Int. CI. 7 H04L 12/56 

(52) U.S. CI 370/401 

(58) Field of Search 370/401-404, 

370/352-356, 233, 254, 469, 475, 389-395; 
379/220, 230, 114.01, 114.09, 221.01; 709/222, 

250, 244 

(56) References Cited 

U.S. PATENT DOCUMENTS 
5,790,634 A 8/1998 Kinser, Jr. ct al. 



5338,683 A 
5,982,780 A 
6,012,152 A 
6,091,708 A 
6,091,732 A 
6,122,363 A 
6,137,874 A 
6,172,981 Bl 
6,182,125 Bl 
6,295,292 Bl 

* cited by examiner 



11/1998 Corleyetal. 

11/1999 Bohmetal. 

1/2000 Douik et al. 

7/2000 Matsunuma 370/233 

7/2000 Alexander, Jr. et al. 

9/2000 Friedlander el al 379/230 

10/2000 Brown et al 379/220 

1/2001 Coxetal. 

1/2001 BorcUa et al. 

9/2001 Voit et al 370/352 



Primary Examiner — Kwang Bin Yao 
Assistant Examiner — Prenell Jones 



(57) 



ABSTRACT 



A call processing network performance verification and 
validation system and test methodology. The call processing 
network implements Internet Protocol (IP) subnet topology, 
ATM WAN configuration, equipment placement, and device 
configuration to provide partitioning of a call processing 
application across multiple sites. The partitioning reduces 
latency for mission critical messages, while providing for 
necessary provisioning traffic needs. Further, the overall 
topology provides the redundancy and resiliency necessary 
for mission critical call processing application, utilizing the 
IP subnets, ATM permanent virtual circuits, network device 
configuration, and server segregation to achieve Quality of 
Service (QoS). The validation testing method and system 
proves out the various segregated routes, verifies subnet 
integrity and measures total latency and data path traversal 
in a verifiable manner. 

27 Claims, 18 Drawing Sheets 
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Case 51 1 (no delay) - CS-TS R/T traffic 204 byte messages, 100 
messages, 10 ms interval, Average=0.00834 ms 90%ile=0 ms 
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Case 512 (no delay) - CS-TS-ATS 204 byte messages, 100 messages, 
10 ms interval Average=0.85 ms 90%ile=0.834 ms 
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Case 513 (with delay) - CS-TS-ATS-GDS R/T traffic, 204 byte message, 
100 messages, 10 ms interval Average=152 ms 90%ile=269 ms 
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Case 514 (with delay) - CS-TS-ATS-remote-GDS, 204 byte messages, 
100 messages, 10 ms interval Average=129 ms 90%ile=230 ms 
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Case 514 (no delay) - CS-TS-ATS-remote GDS R/T traffic, 204 byte 
messages, 100 messages, 10 ms interval Average=2.54 ms 
90%ile=2.50 ms 
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Case 515 (with delay) - TS-SS provisioning, 2040 bytes messages, 
100 messages, Average=15 ms 90%ile=22 ms 
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Case 51 5 (no delay) - TS-SS provisioning, 2040 byte messages, 
100 messages, Average=0.85 ms 90%ile=0.834 ms 
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Case 516 (with delay) FEDS-remote FEDS provisioning over PVC2 on 
WAN, 2040 bytes messages, 100 messages, Average=14 ms 
90%tle=16 ms 
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WAN, 2040 bytes messages, 100 messages, Average=4.21 ms 
90%ile=4.16 ms 
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Case 518 (with delay) - High load LAN latency, R/T traffic, 204 byte messages, 
10000 messages, 1 ms (clock resolution) interval 
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Case 518 (no delay) - High load LAN latency, R/T traffic, 204 byte messages, 
10000 messages, 1 ms (clock resolution) Interval 
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Case 519 (with delay) - High load LAN latency, Provisioning traffic, 2040 byte 
messages, 10000 messages, 1 ms (clock resolution) interval 
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Case 519 (no delay) - High load LAN latency, Provisioning traffic, 2040 byte 
messages, 10000 messages, 1 ms (clock resolution) interval 
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Case 51 10 (with delay) - High load WAN latency, R/T traffic, 204 byte messages, 
10000 messages, 1 ms (clock resolution) interval 
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Case 51 10 (no delay) - High load WAN latency, R/T traffic, 204 byte messages, 
10000 messages, 1 ms (clock resolution) interval 
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Case 51 1 1 (with delay) - WAN high toad provisioning, 2040 byte 
messages, 10000 messages, 1 microsecond interval (clock resolution), 
Average=60 ms, 90%ile=1 1 1 ms 
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Case 51 1 1 (no delay) - WAN high load provisioning, 2040 byte messages, 
10000 messages, 1 microsecond interval (clock resolution), 
Average=4.9 ms, 90%ile=6.6 ms 
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Case 51 12 (with delay) - SS-remote RS, 7 Mbyte messages, 200 
messages, 1 ms interval, Average=8.3 s, 90%ile=8.4 s 
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Case 51 12 (no delay) - SS-remote RS, 7 Mbyte messages, 200 
messages, 1 ms interval, Average=8.2 s, 90%ile=8.3 s 
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VALIDATION OF CALL PROCESSING Internet Protocol (IP) subnet topology, Asynchronous Trans- 

NETWORK PERFORMANCE fer Mode (ATM) WAN configuration, and network devices 

configured for partitioning a call processing application 

CROSS-REFERENCE TO RELATED across multiple LAN sites, meets latency requirements and 

APPLICATIONS 5 routes data as required by a functional call processing 

application. 

The following patent application is a continuation-in-part 

of U.S. application Ser. No. 09/444,099, entitled "Network SUMMARY OF THE INVENTION 
Architecture and Call Processing System," filed Nov. 22, 

1999, now U.S. Pat. No. 6,385,204. Commonly owned, co-pending U.S. patent application 

10 Ser. No. 09/444,099 describes a novel call processing and 

FIELD OF THE INVENTION call traffic provisioning network architecture that includes an 

IP based network LAN/WAN design implementing Internet 

The present invention relates generally to call processing Protocol (IP) subnet topology that may be configured to 

network design architectures, and particularly, to a test prov ide redundancy, reduce latency for mission critical call 

system and methodology for verifying performance of an IP is proccssmg messages, and provide for all necessary traffic 

based LAN/WAN network architecture implementing Inter- provisioning needs. Particularly, the aforementioned call 

net Protocol (IP) subnet topology, Asynchronous Transfer processing and provisioning network topology makes use of 

Mode (ATM) WAN configuration, and network devices subnets, so that traffic may be segregated within a LAN/ 

configured for partitioning a call processing application WAN as desired and allowing for the assignment of specific 

across multiple LAN sites. 20 typcs tQ sp Cci&c interfaces on network devices, e.g., 

nArK-r.RniiNn hf tup tNVPNmrw allowing traffic to be directed to specific permanent virtual 

BACKGROUND OF THE INVENTION circuits (pvCs) m an Am WAN Each pvc fe , Q ^ 

There exist many types of networks and shared informa- configured using priority rate queuing enabling delivery of 
tion communications systems. From a hierarchical ^ specific traffic types in the most mission efficient manner, 
standpoint, network topologies typically comprise a plural- The present invention is directed to a system test and 
ily of local area networks (LANs), such as Ethernet, which, methodology for validating the performance of the novel IP 
depending upon the amount of users, location and amount of based network LAN/WAN design implementing Internet 
traffic, may be further interconnected locally with a high- Protocol (IP) subnet topology. Preferably, the system inte- 
speed backbone network, such as backbone fiber distributed 3Q grates server to server routing, modeling the application's 
data interface (FDDI), and asynchronous transfer mode data route through an application network, in combination 
(ATM) backbone networks. Multiple LANs owned by a with the LAN/WAN network's routing, through subnets, to 
single entity and geographically dispersed, may be intercon- verify subnet integrity, total latency, and data path traversal 
nected via wide area networks (WANs) for long distance in a verifiable manner. Particularly, the method of the 
information transport. Such WAN transport technologies 35 invention validates the round trip latencies by traversing 
may include dial-up private networks, switched digital each application server in the designated routes and order, as 
services, leased -lines, packet-switching and frame-relay well as traversing the required network devices. The tran- 
services, cell relay, and public packet-switched network sition between subnets and the validation of network device 
such as the Internet. It is understood that each type of configurations is proved out as well, 
network is capable of carrying different types of informa- ^ Thus, in accordance with the invention, there is provided 
tion: data, voice, multimedia including audio and video data. a system and method for validating a telecommunications 
As known, ATM networks in particular, are connection call processing network comprising: a call processing net- 
oriented and capable of achieving certain quality of service work including a variety of application servers and network 
(QoS) guarantees so that data, e.g., video, is transported devices for simulating handling of call processing traffic 
across networks to their destinations in a timely manner. 45 along first segregated routes comprising one or more subnets 
Other QoS guarantees include bandwidth control, prioriti- between associated network devices, and handling of call 
zation of selected traffic, and traffic security. provisioning traffic along second segregated routes compris- 

In the telecommunications industry, there exist many ing one or more subnets, the first and second segregated 
types of call processing networks and network topologies for routes segregated according to call traffic latency require- 
carrying prevalent types of traffic such as real-time call 50 ments; test tool capable of communicating test information 
processing traffic, e.g., for toll-free number calls, and ATM packets along selected segregated routes in the call process- 
provisioning traffic, e.g., for other types of prioritized traffic, ing network; and a mechanism for measuring round trip 
Each of these traffic types have differing latency and pro- latencies of communicated packets along the selected seg- 
cessing requirements. In order to meet these differing regated routes, whereby internetwork and intranetwork 
requirements, it is advantageous to provide an overall net- 55 latency and subnet integrity for simulated packet traffic is 
work topology that is physically and logically partitioned to verified. 

enable traffic segregation within a LAN and WAN, as Advantageously, the method and system of the invention 

desired, such that specific traffic types may be segregated to may be used for the validation of call processing networks 

specific interfaces on network devices, and that specific and applications and particularly, of any system involving 

traffic types may be delivered in the most mission efficient ^ servers and network devices in a LAN/WAN. Thus, call 

manner. processing networks may be validated prior to them being 

Furthermore, current call processing network/system vali- built, 

dation techniques comprise server to server validation, or The various features of novelty which characterize the 

validation of network device to network device latencies and invention are pointed out with particularity in the claims 

paths. Consequently, it is highly desirable to provide a 65 annexed to and forming a part of the disclosure. For a better 

comprehensive system and method designed to verify that understanding of the invention, its operating advantages, and 

an IP based LAN/WAN network architecture implementing specific objects attained by its use, reference should be had 
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to the drawings and descriptive matter in which there are 
illustrated and described preferred embodiments of the 
invention. 

BRIEF DESCRIPTION OF DRAWINGS 

FIG. 1 illustrates the NIP LAN/WAN architecture of the 
invention. 

FIG. 2 illustrates the primary functional components of 
each of the production LANs depicted in FIG. 1. 

FIG. 3 illustrates the benchmark topology 400 for testing 
the NIP LAN/WAN production site (of FIG. 2) according to 
the invention. 

FIG. 4 illustrates the NPT tool 500 comprising one or 
more processes running on one or more host servers, e.g., 
DEC alpha, and including NPT tool initiator and daemon 
processes. 

FIG. 5(a) depicts an example logical test configuration 
between a communications server and a transaction over a 
call processing FDDI ring according to the invention. 

FIGS. 5(6) and 5(c) illustrate the packet delay results 
incurred for the example tests of measuring the round trip 
times according to the test configuration of FIG. 5(a) with a 
delay option (FIG. 5(b)) and no-delay option (FIG. 5(c)). 

FIG. 6(a) illustrates the logical test configuration for 
verifying successful packet transfer from a communications 
server to an advanced transaction server according to the 
invention. 

FIGS. 6(6) and 6(c) illustrate the packet delay results 
incurred for the example tests of measuring the round trip 
times according to the test configuration of FIG. 6(a) with a 
delay option (FIG. 6(6)) and no-delay option (FIG. 6(c)). 

FIG. 7(a) illustrates the logical test configuration for 
verifying successful packet transfer from a communications 
server (CS) to a global data server (GDS) according to the 
invention. 

FIGS. 7(b) and 7(c) illustrate the packet delay results 
incurred for the example tests of measuring the round trip 
times according to the test configuration of FIG. 7(a) with a 
delay option (FIG. 7(6)) and no-delay option (FIG. 7(c)). 

FIG. 8(a) illustrates the logical test configuration for 
verifying successful real-time call processing packet transfer 
from a CS to a remote GDS over a WAN according to the 
invention. 

FIGS. 8(6) and 8(c) illustrate the packet delay results 
incurred for the example tests of measuring the round trip 
times according to the test configuration of FIG. 8(a) with a 
delay option (FIG. 8(6)) and no-delay option (FIG. 8(c)). 

FIG. 9(a) illustrates the logical test configuration for 
verifying successful provisioning packet transfer from a 
transaction server to a statistics over a provisioning FDDI 
ring according to the invention. 

FIGS. 9(6) and 9(c) illustrate the packet delay results 
incurred for the example tests of measuring the round trip 
times according to the test configuration of FIG. 9(a) with a 
delay option (FIG. 9(6)) and no-delay option (FIG. 9(c)). 

FIG. 10(a) illustrates the logical test configuration for 
verifying successful packet transfer from a front end data 
server to a back end data server over the a PVC on a WAN 
according to the invention. 

FIGS. 10(6) and 10(c) illustrate the packet delay results 
incurred for the example tests of measuring the round trip 
times according to the test configuration of FIG. 10(a) with 
a delay option (FIG. 10(6)) and no-delay option (FIG. 
10(c)). 
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FIG. 11(a) illustrates the logical test configuration for 
verifying successful packet transfer from a statistics server 
to a report server (RS) over the WAN according to the 
invention. 

s FIGS. 11(6) and 11(c) illustrate the packet delay results 
incurred for the example tests of measuring the round trip 
times according to the test configuration of FIG. 11(a) with 
a delay option (FIG. 11(6)) and no-delay option (FIG. 11(c)). 
FIGS. 12(a) and 12(6) illustrate the path latency results 

10 when an example CPFR high load LAN real-time traffic 
benchmark test is run with a delay option (FIG. 12(a)) and 
without the delay option (FIG. 12(6)) according to the 
invention. 

s FIGS. 13(a) and 13(6) illustrate the path latency results 
when an example LAN High Load provisioning traffic 
benchmark test is run with a delay option (FIG. 13(a)) and 
without the delay option (FIG. 13(6)) according to the 
invention. 

20 FIGS. 14(a) and 14(6) illustrate the path latency results 
when an example PFR WAN Real-Time High Load provi- 
sioning traffic benchmark test is run with a delay option 
(FIG. 14(a)) and without the delay option (FIG. 14(6)) 
according to the invention. 

25 . FIGS. 15(a) and 15(6) illustrate the path latency results 
when an example WAN Real-Time High Load provisioning 
traffic benchmark test is run with a delay option (FIG. 15(a)) 
and without the delay option (FIG. 15(6)) according to the 
invention. 

30 FIGS. 16(a) and 16(6) illustrate the path latency results 
incurred when an example WAN Statistics High Load traffic 
test is run with a delay option (FIG. 16(a)) and without the 
delay option (FIG. 16(6)). 

FIG. 17 illustrates a logical test configuration 400 for a 
Dual NIC Impact test according to the preferred embodi- 
ment of the invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENT 

40 

FIG. 1 illustrates the Network Intelligent Peripheral 
"NIP" topology 100 as described in commonly-owned, 
co-pending U.S. patent application Ser. No. 09/444,099, the 
contents and disclosure of which is incorporated by refcr- 

45 ence as if fully set forth herein. As shown in FIG. 1, the 
"NIP" topology 100 includes a private ATM backbone WAN 
105 and/or backup ATM WAN 105a comprising one or more 
BPX ATM switches for linking three or more distinct LAN 
network sites 200a-200c. The ATM WAN 105/back-up 

50 ATM WAN 105a implements private point-to-point ATM 
links depicted in FIG. 1 as links HOa-llOc between the 
respective NIP LAN sites 200a-200c, respectively. The Hot 
Standby Backup Network (HSBN) 106 is implemented as a 
backup network, for connectivity to the monitoring com- 

55 mand system (MCSS) 115, as well as other System/Network 
management sites 120. As will be hereinafter described in 
greater detail, each NIP LAN site 200a-200c comprises: a 
real-time call processing LAN, a provisioning LAN, and the 
Intelligent Peripheral LAN. As will be described, with the 

60 NIP network topology 100 depicted in FIG. 1, network 
latencies are minimized to meet Statement of Network 
Requirements (SONR) for real-lime traffic, in particular that 
traffic which must traverse the WAN. 
Although the LAN configuration of the different sites may 

65 vary, FIG. 2 illustrates the general configuration of each 
network intelligent peripheral ("NIP") LAN site, e.g., LAN 
site 200a. As shown in FIG. 2, the LAN site 200a includes 



06/09/2004, EAST version: 1.4.1 



US 6,618389 B2 



a real-time call processing LAN, such as implemented by a 
Call Processing FDDI Ring ("CPFR") 217, and a provision- 
ing LAN, such as implemented by a Provisioning FDDI 
Ring ("PFR") 247. As will be explained herein in greater 
detail, the PFR 247 is physically split between two or more 
provisioning GeoLAN hubs 260 and two or more provision- 
ing LAN GIGAs witches 250 with the GeoLAN hubs com- 
prising traditional FDDI ring technology, while the 
GIGAswitches 250 are non-blocking, cross-bar switched 
and exploited for their higher bandwidth (as compared to the 
standard FDDI implementation). The FDDI ports on both 
the CPFR and the PFR are dual homed such that the "A" port 
of a given FDDI port is connected to one hub of a given ring, 
while the "B" port is connected to the other hub of that ring 
247. This configuration ensures that the loss of any given 
hub does not bring down the ring. Additionally, each LAN 
site may include the following systems: 

1) two or more communication servers 220 ("CS") for 
providing simultaneous communications services, e.g., 
transfer files, access information on systems or networks, for 
one or more users on the network, and which may comprise 
a DEC Alpha Server 4100 having a digital UNIX operating 
system, and, interfaced with mass storage devices (not 
shown) and the call processing FDDI 217; 

2) two or more Memory Channel Hubs (TS/OCS) 202 
which include CCMAA cards for interfacing with a bus and 
enabling direct memory data transfer between systems; 

3) two or more transaction servers ("TS") 204 for bro- 
kering call requests for call routing information and sending 
the information back to the CS, and which may comprise a 
DEC Alpha Server 4100 having a digital UNIX operating 
system, and, interface with mass storage devices (not 
shown), the call processing FDDI 217, the provisioning 
FDDI ring 247, and memory channel hubs via CCMAA 
memory channel cards (not shown). Preferably, each TS 201 
has three FDDI ports (ftaO, ftal & fta2) and each ATS 205 
has two FDDI ports (ftaO and ftal). Assuming ftaO (and ftal 
for the TS) is connected to the CPFR 217 and ftal (fta2 for 
the TS) are connected to the PFR 247 for each server. This 
port split allows all real-time traffic to be prioritized by the 
server out to the real-time ring, while provisioning traffic is 
directed to the provisioning ring. Thus, different traffic types 
are segregated physically as well as logically, placing real- 
time bandwidth demands where appropriate. The multiple 
interfaces for the TS 204 on the same FDDI ring are due to 
Digital UNlXs' inability to handle multiple subnets on the 
same physical interface; 

4) two or more Advanced Transaction Servers ("ATS") 
205 which performs as the TS, however, provides more 
complicated services; 

5) two or more global data servers ("GDS") 295 which 
provide call routing information to the TS & ATS and, which 
may additionally provide call routing information across the 
WAN to other sites. These servers may comprise a DEC 
Alpha Server 4100 having a digital UNIX operating system, 
and, interfaced with mass storage devices (not shown), the 
call processing FDDI 217, and an associated memory chan- 
nel hub 298 via CCMAA memory channel cards (not 
shown); 

6) two or more Overload Control Servers 210 which 
provide a busy signal for calls as the application approaches 
overload of it's call capacity. These servers may comprise a 
DEC Alpha Server 4100 having a digital UNIX operating 
system, and, interface with mass storage devices (not 
shown), the call provisioning FDDI ring 247, and memory 
channel via CCMAA memory channel cards (not shown); 
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7) two or more Back End Data Servers ("BEDS") 225a 
for back ups and provisioning data, and two or more Front 
End Data Servers ("FEDS") 2256 for back ups and provi- 
sioning data. Each of these systems may comprise a DEC 
Alpha Server 4100 having a digital UNIX operating system, 
interface with mass storage devices (not shown), and inter- 
face with the provisioning LAN Gigaswitches 250; 

8) two or more Statistics Servers ("SS") 230 which gather 
call statistics from the TS & ATS servers and which may 
comprise a DEC Alpha Server 4100 having a digital UNIX 
operating system, interface with mass storage devices (not 
shown), and interface with the provisioning LAN 
Gigaswitches 250; 

9) two or more Alarm Collection Processors (" ACP') 240 
15 which gather the application alarms from throughout the 

application space and which may comprise a DEC Alpha 
Server 1200 having a digital UNIX operating system, inter- 
face with mass storage devices (not shown), and interface 
with the provisioning FDDI ring; 

10) two or more Alarm Distribution Processors ("ADF') 
235 which take the gathered alarms and displays them to 
various operational personnel and, which may comprise a 
DEC Alpha 4100 Server having a digital UNIX operating 
system, interface with mass storage devices (not shown), 
and interface with the provisioning FDDI ring; 

11) two or more Terminal Servers 245 which provide a 
plurality of ports available for system console port connec- 
tivity and may comprise a DECServer 700; 

12) an NIP Manager 264 which may comprise a DEC 
Alpha 4120 Server having a digital UNIX operating system, 
and provided with systems for interfacing with mass storage 
devices (not shown); 

13) an NIP Manager Onsite 266 which may comprise a 
DEC Personal workstation having a digital UNIX operating 
system, and associated displays and systems for interfacing 
with mass storage devices (not shown) and the etheraet LAN 
219;. 

13) two or more Openview Servers 248 such as provided 
by Hewlett Packard (HP) which provide network manage- 
ment system functionality; 

14) two or more sets of GeoLAN Hubs 270 which provide 
for the configuration and monitoring of the GeoLAN Call 
Processing FDDI hubs 217; 

15) one or more routers 280 such as router models 7507 
manufactured by Cisco Systems, Inc. for routing control 
calls to the HSBN MPRN (MCSS Host) from the LAN site, 
e.g., site 200a; 

16) a firewall 285 providing secure interface between the 
router 280 and the GIGAswitch 250 of the LAN site; 

17) two routers 290 such as router models 7513 Routers 
manufactured by Cisco Systems, Inc. which provide an 
interface to the private ATM backbone WAN 105 and/or 
backup ATM WAN 105a. Preferably, permanent virtual 
circuits (PVCs) are provisioned from the router 285 to BPX 
switches (not shown) in the ATM backbone which use the 
full 155 Mbps bandwidth of the BPX switch. However, no 
traffic shaping is done in the router — rather, the BPX 
switches shape the traffic over the PVCs as will be herein- 
after described in greater detail. The Cisco 7513 routers* 
FDDI interfaces utilize the Hot Standby Routing Protocol 
(HSRP) available from Cisco System Inc. and described in 
a product bulletin available from Cisco Systems, the con- 
tents and disclosure of which is hereby incorporated by 
reference, to provide for failover to the standby router in 
case of a LAN port failure, either on the router or on a hub. 
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This protocol goes into effect when the LAN connection is 230 via the PFR 247 and the GIGAswitch 250; messages 

Lost, and fails the mission traffic flow over to the standby between a CS 220 and a local GDS 295 at the same site by 

router. Use of HSRP is necessitated by the slow recover way of the TS 204, the ATS 205, and the CPFR 217 (and 

times of RIP or Interior Gateway Routing Protocol (IGRP). reverse); messages between a CS 220 and a GDS 295 at a 

relative to NIP mission requirements. Moreover, the Cisco 5 remote site by way of the TS 204, the ATS 205, the CPFR 

7513 routers utilize the Enhanced Interior Gateway Routing 217 to the router 290 and from the router via an OC3 

Protocol (EIGRP) an the ATM OC-3 interfaces to the BPX connection to a first ATM BPX switch 275a associated with 

switches to provide for failovcr routing in the event of NIP LAN site, e.g., site 200a, and through a PVC pipe 

interface or link loss to the switches. The failure of one inter (represented by ATM cloud 105) to a second ATM BPX 

BPX link out of the two causes the switch to route all traffic J(J switch 2756 associated with remote NIP LAN site, e.g., site 

over the remaining link, using the minimum specified bit 2006, to a router 290 at the remote site via an OC3 

rates for each PVC. Loss of all inter BPX links on one site connection and finally to the remote GDS 295 through 

to site path switch forces EIGRP protocol to route data via CPFR 217 at the remote site; and, messages between a SS 

the other switch at the site. Referring back to FIG. 1, if all 220 and a RS 292 at a remote site by way of the GIGAswitch 

site to site pathways for all switches at a site are lost, the J5 250 to the router 290 and from the router via an OC3 

traffic is routed over the HSBN WAN depicted as WAN connection to a first ATM BPX switch 275a associated with 

cloud 106. This option requires the total isolation of the NIP LAN site, e.g., site 200a, and through a PVC pipe 

site's private WAN links, i.e., the severing of three E-3 links . (represented by ATM cloud 105) to a second ATM BPX 

Preferably, Available Bit Rate (ABR) guarantees that the switch 2756 associated with remote NIP LAN site, e.g., site 

real-time ATS-GDS link is the first recovered, i.e., the 2Q 2006, to a router 290 at the remote site via an OC3 

ATS-GDS link is apportioned whatever bandwidth there is, connection and finally to the remote RS 292 via the 

so in the context of a recovering set of links on a switch, this GIGAswitch 250 at the remote site. As will be appreciated 

link comes back first. Note this only applies to ATS-GDS by skilled artisans, messages are contained within the FDDI 

links to be established across the WAN between sites, not the ring 217 via the token matching mechanism with each 

Call Processing LAN 217 at a site. ^ station on the ring receiving the passed token with each 

Other types of equipment that may be included at a LAN message. If the token does not match that station's token, the 

site include a network printer 236 connected with Ethernet token/message is passed on to the next station. Once the 

LAN 219; a report server ("RS") 292 for gathering statistical token matches the station token address, the IP address of the 

data from statistics servers on call services information; and, message is matched to an IP port address. Messages meant 

an IP voice provisioning box (VPB) 294. 30 to leave the ring are sent to the gateway, which is the Rules 

A detailed description of the operation of the NIP network Based Router (RBR), i.e., a server acting as a router, 

is found in aforementioned co-pending U.S. patent applica- As further shown in FIG. 2, messages destined for the 

lion Ser. No. 09/444,099. As described, the suite of servers PFR 247 are typically provisioning and support data flows, 

in each given ring (CPFR 217 & PFR 247) are each dual The PFR 247 consists of the FDDI hubs and the 

homed; further, half of the servers of a given contingent 35 GIGAswitches 250a,6, which together form the logical 

(e.g., the CS's) are connected to one card in the given hub, FDDI ring. That is, the GIGAswitches are a logical exten- 

while the other half is connected to another card in the hub. sion of the FDDI ring and provide for the configuration and 

Thus, network architecture is enabled to maintain a mission monitoring of the GeoLAN FDDI hubs. As deduced from 

capability, albeit degraded, in case a given card in the two FIG. 2, example message flows involving the PFR 247 may 

hubs has failed. To support this configuration, the architec- 40 include: TS 204 to SS 230 (PFR) multicast; ATS 205 to SS 

ture employs a Spanning Tree Protocol (S IT) (proprietary to (PFR) multicast; from varied systems to an ADP 235 (PFR 

Cisco Systems, Inc.) which must be turned off to prevent and GIGAswitch); from varied systems to the ACP 240 

failover times in excess of 45 seconds. With STPoff, failover (PFR and GIGAswitch); HP Openview Manager server 248 

times are less than three seconds. Additionally, with STP off, (PFR and GIGAswitch) from network devices; NM On-site 

the LAN topology must avoid loops involving the 45 266 from ADP 235 and BEDS-FEDS (local is GIGAswitch 

GIGAswitches, lest a network loop be created. only); IP VPB (local is GIGAswitch only) which is a 

Messages destined for the CPFR 217 are typically real- separate box for the Intelligent Peripheral; SS 230 to RS 292 

time, high-priority data flows dealing with call processing, (local is GIGAswitch only); BEDS to TS/ATS (PFR and 

with minimal management traffic. As further shown in the GIGAswitch); MCSS to FEDS; FEDS to FEDS; and, the 

NIP LAN site 200a of FIG. 2, these call processing mes- 50 A°P 235 to a Network Manager Remote (NMR). 

sages flow via lines 221 into the CPFR 217 particularly from As the majority of the traffic from outside of the PFR 247 

a CS 220 from the Call Transmission Network ("CTN") is expected on the cross WAN, SS to RS data transfer, e.g., 

network. Additional traffic into the CPFR include messages which is approximately 7 Mb every minute, with a less than 

from a remote ATS 205 over lines 207, destined for the GDS 4 second delivery window, the NIP architecture is sized for 

295. Other types of traffic may be routed from the Cisco 55 three such transactions simultaneously. The same applies to 

7513 router 290 into the CPFR 217 via line 209. Outgoing message flow out of the PFR. With respect to provisioning 

message flows from the CPFR 217 are primarily from the CS and support data message flows within the PFR ring 247, 

to the CTN network, and, from the ATS to a remote GDS via these messages typically include, but are not limited to: 

lines 208. flows between the TS and SS (PFR); ATS to SS (PFR); from 

Example message flows to be routed within the CPFR 217 w varied systems to the ADP (via PFR and GIGAswitch); from 

include, but are not limited to, the following: messages from varied systems to ACP (via PFR and GIGAswitch); HP 

the CS 220 to the TS 204 (and reverse) and messages routed Openview server (via PFR and GIGAswitch); NM On-site; 

from the TS 204 to an ATS 205 via the CPFR 217; messages BEDS-FEDS (local is GIGAswitch only); IP VPB (local is 

from the CS 220 to the TS 204 via the CPFR 217 and routed GIGAswitch only); SS to RS (local is GIGAswitch only); 

from the TS 204 to an 800 call processing server 216 via the 65 and BEDS to TS/ATS (via PFR and GIGAswitch). 

CPFR 217 (and reverse); messages (multicast) between a As mentioned above, the PFR 247 is physically split 

transaction/advanced transaction server 204/205 and the SS between GeoLAN hubs 260a and GIGAwitches 250. This 
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split of the PFR into GeoLAN hubs 260a and GIGAwitches 
250 allows the ring to carry more traffic than a traditional 
FDDI ring. The GIGAswitches add more FDDI ports to the 
ring, without additional ring latency increases. Adding new 
subnets or LAN segments off of the GIGAswitches do not 
necessarily require the routers. 

Furthermore, as described in aforementioned co-pending 
US. patent application Ser. No. 09/444,099, the NIP is 
logically configured to meet Real-Time call processing 
traffic (e.g., CS-TS), ATS-GDS traffic, and provisioning 
traffic requirements. Real-Time call processing traffic, ATS- 
GDS traffic, and provisioning traffic each have differing 
latency requirements. In order to meet these differing 
requirements, subnets are employed to separate the traffic 
types within the LAN and WAN, as desired. Each subnet 
enables the assignment of specific traffic types to specific 
interfaces on network devices. These interfaces are to be 
optimised in various ways (e.g., using NetFlow). 
Additionally, segregated traffic may be directed to specific 
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numbers and types of interfaces and network paths so that 
the required tests may be completed. It is understood that a 
benchmark test set-up may be provided which may com- 
pletely duplicate a production site (e.g., of FIG. 2). As 
shown in FIG. 3, for testing purposes, each of the following 
systems corresponding to a server device implemented in the 
NIP LAN/WAN architecture network, and may be physi- 
cally implemented, for example, by a DEC Alpha series 
server device. These blocks include: system A (FEDS); 
system B (GDS); system C (ATS); system D (TS); system E 
(CS); system F (RS, SS); and system T (Remote GDS). 
Systems G, H and I includes a Cisco 7513 Router; while 
systems K, J and L are the GIGASwitches. Systems P and Q 
are the call provisioning FDDI ring GeoLan Hubs while 
systems R and S are the call processing FDDI ring GeoLan 
Hub. Systems M and N are the BPX traffic shaping switches. 

According to a preferred embodiment, as shown in FIG. 
3, the benchmark test system of the invention implements a 
lest tool 500, herein referred to as a Network Path Test Tool 



PVCs in the ATM WAN cloud 105 (FIG. 1), with each PVC 20 (" NPT ? which > « its most simple mode, sends packets to a 



further configured using priority rate queuing in the BPX. 
These optimising configurations enables the tuning of the 
NIP LAN/WAN to deliver specific traffic types in the most 
mission efficient manner. 



targeted remote system, and receives returned packets. The 
NPT tool 500 logs the returning packets, and compares 
timestamps to determine the length of the round trip. 
Preferably, the tool runs in user mode, and assembles 



following, but are not limited to: real-time call processing 
(e.g., CS-TS traffic), ATS-GDS traffic, provisioning traffic, 
and even a dedicated subnet for SS-RS traffic. The creation 
of the PVCs for the WAN also necessitates the allocation of 
another subnet. As shown in FIG. 2, each subnet (indicated 
by the number in the left column) is allocated a mission, 
detailed below. 

TABLE 1 

Subnet Missions 



30 



35 



IP 

No. 



Subnet Mission 



40 



45 



„ i u • • . c packets that are then passed onto an IP socket interface. The 

For example, the mission traffic profiles include the * NFrte ^ miysendc 4 erTC PorUDPpacket S ,aiid supports 

the TCP_NODELAY socket option. An optional file speci- 
fication may cause the contents of the file to be passed along 
as payload data within each packet. 

As will be further described herein, for more complex 
testing, the NPT tool runs test suites including scripts which 
may send the packet through a sequence of systems and 
back, allowing for the computation of round trip delays for 
the network along an application communication path. 
Furthermore, an additional script may be added to the test 
suite that performs a traceroute to every interface address 
and hostname. The purpose of this demonstrates that the host 
files and routers are correctly set up, and that packets 
between specific systems followed the correct paths. Packets 
are only transmitted via an interface's primary address, the 
secondary address is used only for receiving packets. This 
means that, for instance, real-time subnet 2 traffic e.g., from 
the ATS, may be sent via the subnet 3 provisioning interface. 
Analysis of the output of this script from each system is used 
to validate the router configurations. 

More specifically, as shown in FIG. 4, the NPT tool 500 
comprises one or more processes running on one or more 
host servers, e.g., DEC alpha, and includes an NPT tool 
initiator process 502 and daemon processes 504. 
50 Specifically, the Network Path Test Tool Initiator 502 pro- 
vides a command line interface 505 that enables a user to 
specify a series of hosts through which a data buffer will be 
sent. The characteristics of the data buffer may be specified 
as well as the sending behavior and the protocol used. The 
55 buffers arc timestamped and marked with a unique sequence 
number before leaving the initiator. This starting timestamp 
is later used to calculate transmit times through the specified 
scries of host servers 510a, . . . ,510/1, and back to the 
initiator host. The IP Network Path Test Tool Initiator 502 
60 works in conjunction with an IP Network Path Test Tool 
Daemon 504 that moves the buffer from host server to host 
server, according to the desired test path, and to report the 
elapsed time at the final host as illustrated in FIG. 4. 

According to the invention, required command line inputs 
for the IP Network Path Test Tool Initiator include at least 
one hostname and one port number. Up to 40 hoslnames may 
be specified. Each hostname must have a corresponding port 



Real-Time Call Processing Traffic 
ATS-GDS Real-Time Call Processing Traffic 
Provisioning Traffic (this will consist of three 
separate entire class C addresses, and is not an 
actual subnet of the three previously defined 
class C addresses) 
SS-RS Traffic 

WAN Primary Link PVCs (out of the XX.YYY.2Z.0 
address space) 

WAN Secondary Link PVC (out of the XX-YYY.ZZ + 1.0 
address space) 

Allocated as a separate set of Class C addresses 
for the IP 

Allocated for IP Ethernet Management Rail 



The PVCs for the ATM WAN likewise fall in the follow- 
ing categories: real-time call processing (ATS-GDS), pro- 
visioning traffic and SS-RS data transfers. Traffic which does 
not explicitly fall into a given category defaults to the 
provisioning PVC. The priority rate queuing figures for the 
real-time and provisioning traffic may be derived in accor- 
dance with conventional techniques known to skilled arti- 
sans. For example, the SS-RS traffic may be given the full 
bandwidth of an E-3 link (34 Mbps link) to facilitate the data 
transfer and meet the application's timing requirements. 

The benchmark topology 400 for testing the NIP LAN/ 
WAN production site (of FIG. 2) according to one embodi- 
ment of the invention is now described herein in view of 65 
FIG. 3. The high-level configuration depicted in FIG. 3 is 
exemplary as it is configured to provide only the correct 
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number. Thus, for test scripts utilized by the NPT tool, the 
following are the required command line arguments utilized: 
-h which is an argument used for indicating the valid 

hostname or IP address entered as, e.g, 123.456.78.90 

or, e.g., mciwcom.host.com; and, 
-p which is an argument used for indicating the valid port 

number on the corresponding host. 
Optional command line arguments for the IP Network 
Path Test Tool Initiator include: 
-f which is an argument used for indicating the full path 

and filename of a file containing additional data to be 

sent. The default is no additional data; 
-n which is an argument used for indicating the number of 

messages to be sent. The default is 0, to continue to 

send forever; 

-i which is an argument used for indicating the interval 
between messages in microseconds. The default is 0 
sec, to send continuously; and, 

-r which is an argument for specifying the protocol type 
(e.g. 0-UDP 1-TCP, default-1). 

The command line inputs are then validated and a mes- 
sage buffer to send to the host is built based on the 
arguments. Preferably, the message buffer is built as follows: 
4 byte remaining size (which is the total size of the message 
buffer -4); 4 byte sequence number; four (4) byte number of 
hosts; the number of hosts*(16 bytes containing the host 
address, port, and timestamp); the host address; the host 
port; the timestamp; and, the records from the payload file 
(if there are any). For the TCP protocol, a connection 
oriented streams based socket is created to pass the data 
buffer to the upstream host servers which connection is to 
the Network Path Test Tool Daemon process 504. For the 
UDP protocol, a connectionless 'datagram socket is created 
to the host. It is understood that all of the NPT initiator and 
daemon processes must be started running the same 
protocol, either TCP or UDP. Finally, the data buffer that is 
generated by the initiator is sent at specific intervals for as 
many repetitions as specified by the command line argu- 
ments. Each time a new buffer is sent, a new sequence 
number and timestamp is calculated. 

The IP Network Path Test Tool Daemon process 504 
works in conjunction with the IP Network Path Test Tool 
Initiator by providing a mechanism to receive buffers from 
the downstream processes, timestamp the buffers, and send 
the buffers to upstream processes. If this particular process 
is the last in the specified series of processes, this process 
will calculate and display the elapsed roundtrip time of the 
buffer in microseconds. 

For test scripts utilized by the NPT Tool Daemon, the 
following is the required command line argument: 

-p an argument indicating a valid port number. 

Optional command line arguments for the IP Network 
Path Test Tool Daemon include: 

-r an argument indicating the protocol type (e.g., 0-UDP, 
1-TCP, default-1); 

-d an argument indicating presence of an optional debug 
file for storing sequence numbers and timestamps of 
buffers passing through the process; and, 

•z an argument indicating a fork off a daemon process. 
The default is the process is not a daemon. 

The command line inputs are then validated and a socket 
is created. The type of socket created depends on what 
protocol is being used. For TCP a connection oriented 
streams based socket is created which listens for incoming 
connection requests, and accepts connection requests. For 
UDP a connectionless datagram socket is created. 



Once the socket to the downstream process has been 
created, the data buffer received from the downstream 
process is processed and sent to the next process in the chain 
(if there is one). If this is the last process in the chain, then 
5 this process calculates and displays the elapsed roundtrip 
time of the data buffer, for example, in microseconds. It 
should be understood that the all processes must be started 
running the same protocol (TCP or UDP) and the final 
Network Path Test Tool Daemon process which calculates 
10 the elapsed time must reside on the same host as the 
Network Path Test Tool Initiator process or else the resulting 
elapsed timestamp will not make any sense due to possible 
clock differences on the various hosts. Furthermore, if the 
Network Path Test Tool Daemon process is run as a daemon 
process (i.e., daemon flag set on), error messages will not be 
displayed to standard terminal output because daemon pro- 
cesses are not attached to a terminal process. 

An example command line illustrating a traversal from 
host 0 to host 1 to host 2 back to host 1 to host 0 in 
accordance with scripts found in Appendix B is as follows: 
npt-h<l" host>-p2001-h<2" < ' host>- P 2001-h<l" host>- 
p2002-h<Oth host>-p2002 

In accordance with the benchmarks established for the 
NIP LAN/WAN design of FIG. 2, and executed by the NPT 
tool 500 configured for test in accordance with the bench- 
mark topology of FIG. 3, the test methodology of the 
invention comprises at least the following functional test 
groups, including but not limited to: 1) Path Validation & 
Latency Measurements including tests for verifying that 
messages are going by the intended paths and for measuring 
round trip latencies. As an example, such test may be used 
to establish whether there are some hidden paths that could 
make the GIGAswitches disable links. Test for LAN latency 
are also included which will ultimately be affected by the 
number of stations on the FDDI rings; 2) Dual NIC Impact 
for testing the impact of dual FDDI NIC cards in an ATS 
system; 3) Failover/Failback to evaluate timings for LAN/ 
WAN component failure modes and LAN/WAN component 
fallback; and, 4) High Load Multiple Data Set Network 
Impact test for verifying real-time, provisioning and SS-RS 
data across the WAN. 
Path Validation & Latency Measurements 

As mentioned above, a critical benchmark test includes 
the Path Validation & Latency Measurements test. Accord- 
ing to the invention, the following tests are configured to 
ensure that traffic uses the intended network paths: a) 
CS-CPFR-TS which verifies basic Communications Server 
(CS) to Transaction Server (TS) connectivity path through 
the Call Processing FDDI Ring (CPFR) such as illustrated in 
50 FIG. 5(a). As the underlying technology is reliable and 
mature, this test is for latency data; b) a CS-CPFR-TS- 
CPFR-ATS test which verifies performance of the connec- 
tivity path from CS to TS over subnet 1, and then from TS 
to the ATS via subnet 2, such as illustrated in FIG. 6(a); c) 
a CS-CPFR-TS-CPFR-ATS-CPFR-GDS (local) test which 
verifies performance of the communications path from the 
CS to the local GDS, such as shown in FIG. 7(a); d) a 
CS-CPFR-TS-CPFR-ATS-CPFR-Cisco 7513 FDDI-Cisco 
7513 ATM-BPX-BPX-Cisco 7513 ATM-Cisco 7513 FDDI- 
CPFR-GDS (remote) test which verifies performance of the 
worst case real time connectivity path to a remote GDS such 
as shown in FIG. 8(«); e) a TS-PFR-GIGAswitch-SS test 
which verifies performance of the connectivity path from the 
TS to the SS via the PFR and GIGAswitch such as shown in 
FIG. 9(a), and which configuration may be considered 
identical to that using an ATS from a network point of view; 
f) a FEDS-GIGAswitch-Cisco 7513-BPX-BPX-Cisco 7513- 
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GIGAswitch -BEDS lest which verifies performance of the starting NPT test Daemons on systems C, E and D (see FIG. 

connectivity path from the FEDS across WAN path to the 3) using executable script startnpt, provided in Appendix B, 

distant FEDS, such as illustrated in FIG. 10(a); g) a this test methodology is initiated on system E in accordance 

SS-GIGAswitch-Cisco 7513-BPX-BPX-Cisco 7513- with executable test scripts entitled casel2d (delay) and 

GIGAswitch-RS test which verifies performance of the s casel2nd (no delay) scenarios, with example scripts being 

connectivity path from the SS to RS path across the WAN provided in Appendix B. The round trip times for messages 

such as shown in FIG. 11(a); h) a LAN High Load R/T test traversing this path according to these example test scripts 

for verifying the impact of flooding the Call Processing arc recorded. FIGS. 6(6) and 6(c) illustrate the results of the 

LAN with real-time traffic; i) a LAN High Load Provision- example tests for measuring the round trip times from the CS 

ing test for verifying the impact of flooding the Provisioning to to the TS to the ATS, then back to the CS with a delay option 

LAN with provisioning traffic; j) a WAN High Load R/T test (FIG. 6(b)) and no-delay option (FIG. 6(c)). Recorded 

for verifying the impact of flooding the WAN with real-time roundtrip times in the 1-2 ms range for a three -system 

traffic; k) a WAN High Load Provisioning test for verifying roundtrip is well within the desirable performance require- 

the impact of flooding the WAN with real-time traffic, and, ments and is clearly met as shown in the test results for the 

1) a WAN High Load SS-RS test for verifying the impact of 15 no delay option illustrated in FIG. 6(c). 

flooding the WAN with SS-RS traffic. FIG. 7(a) illustrates the logical test configuration for the 

Preparation for each lest includes the following proce- CS-CPFR-TS-CPFR-ATS-CPFR-GDS (local) connectivity 

dures: For each server, e.g., DEC Alpha, used in the test, the path which verifies successful packet transfer from CS to 

following test directories are created: Aest, /test/data, /test/ GDS with no extraneous routes and, the successful transition 

store, /test/scripts and /test/bin. The NPT daemon and ini- 20 of the packet from subnet 1 to subnet 2. According to one 

tiator executable are then placed on each server in the embodiment of the CS-CPFR-TS-CPFR-ATS-CPFR-GDS 

/test/bin directory, and the test scripts are placed on each (local) benchmark test methodology of the invention, 100 

server in the /test/scripts directory. For UNIX server devices, messages are transmitted at 10 millisecond intervals from 

the default UNIX path is set to include /test/bin and /test/ the CS directed to the TS which redirects test message 

scripts. Each server is configured with the IP addresses for 25 packets to ATS which ATS redirects lest message packets to 

each site as shown in Appendix A with verification of all GDS (local) which finally returns packets to the CS via 

each network device configuration. traversed route. After starting NPT test Daemons on systems 

Each of the above mentioned tests will now be described B, C, E and D (see FIG. 3) using executable script startnpt, 
tests will now be described in further detail. Particularly, provided in Appendix B, this test methodology is initiated on 
FIG. 5(a) illustrates the logical test configuration for the 30 system E in accordance with executable test scripts entitled 
CS-CPFR-TS connectivity path which verifies successful cascl3d (delay) and casel3nd (no delay) scenarios, with 
packet transfer from CS to TS over the FDDI, with no example scripts being provided in Appendix B. The round 
extraneous routes, via subnet 1 (I P_l) addresses. According trip limes for messages traversing this path according to 
to one embodiment of the CS-CPFR-TS benchmark test these example test scripts are recorded. FIGS. 7(6) and 7(c) 
methodology of the invention, 100 messages are transmitted 35 illustrate the packet delay results incurred for the example 
at 10 millisecond intervals from the CS directed to the TS, tests of measuring the round trip times from the CS-TS- 
which are then directed back to the CS. After starting NPT ATS-GDS (local) with a delay option (FIG. 7(6)) and 
test Daemons on systems E and D (see FIG. 3) using without the delay option (FIG. 7(c)). 
executable script startnpt, as provided in Appendix B, this FIG. 8(a) illustrates the logical test configuration for the 
test methodology is initiated on system E in accordance with 40 CS-CPFR-TS-CPFR-ATS-CPFR-Cisco 7513 FDDI-Cisco 
test scripts entitled caselld (delay) and casellnd (no delay), 7513 ATM-BPX-BPX-Cisco 7513 ATM-Cisco 7513 FDDI- 
the example scripts being provided in Appendix B. The CPFR-GDS (remote) connectivity path for verifying sue- 
round trip times for messages traversing this path according cessful packet transfer from a CS to remote GDS over the 
to these example test scripts are recorded. All tests may be WAN, with no extraneous routes, using subnet 2 (real-time 
performed twice, with the TCP delay on and TCP delay off. 45 call processing traffic). According to one embodiment of the 
FIGS. 5(6) and 5(c) illustrate the packet delay results CS-CPFR-TS-CPFR-ATS-CPFR-Cisco 7513 FDDI-Cisco 
incurred for the example tests that measure round trip times 7513 ATM-BPX-BPX-Cisco 7513 ATM-Cisco 7513 FDDI- 
from the CS to the TS, then back to the CS with a delay CPFR-GDS (remote) benchmark test methodology of the 
option (FIG. 5(6)) and no-delay option (FIG, 5(c)). As invention, 100 messages are transmitted at 10 millisecond 
shown in. FIG. 5(6) there is illustrated the packet delays 50 intervals from the CS directed to the TS which redirects 
incurred for messages sent by not utilizing the TCP_ message packets to ATS which redirects the message packets 
NODELAY socket option, i.e., with delay. As shown in the to the GDS (remote) which finally returns packets to the CS 
CS-TS results of FIG. 5(6), cyclic pattern in the roundtrip via the traversed route. After starting NPT lest Daemons on 
times suggests a buffer related mechanism may be at work. systems T, C, E and D (see FIG. 3) using executable script 
As shown in FIG. 5(c), the roundtrip times recorded are in 55 startnpt, provided in Appendix B, this test methodology is 
the sub-millisecond range which indicates normal expected initiated on system E in accordance with executable test 
LAN performance for this type of traffic. script entitled casel4d (delay) and casel4nd (no delay), with 

FIG. 6(a) illustrates the logical test configuration for the example scripts being provided in Appendix B. The round 

CS-CPFR-TS-CPFR-ATS connectivity path which verifies trip times for messages traversing this path according to 

successful packet transfer from the CS to ATS with no 60 these example test scripts are recorded. FIGS. 8(6) and 8(c) 

extraneous routes and, the successful transition of the pack- illustrate the packet delay results incurred for the example 

ets from subnet 1 to subnet 2. According to one embodiment tests of measuring the round trip times from the CS-TS- 

of the CS-CPFR-TS-CPFR-ATS benchmark test methodol- ATS-GDS (remote) with a delay option (FIG. 8(6)) and 

ogy of the invention, 100 messages are transmitted at 10 without the delay option (FIG. 8(c)). 

millisecond intervals from the CS to the TS (via the CPFR) 65 FIG. 9(a) illustrates the logical test configuration for the 

which redirects the message packets to ATS which finally TS-PFR-GlGAswitcb-SS connectivity path for verifying 

returns packets to the CS via the traversed route. After successful packet transfer from a TS to an SS with no 
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extraneous routes via subnet 3 (Provisioning traffic). 
According to one embodiment of the TS-PFR-GIGAswitch- 
SS benchmark test methodology of the invention, 1000 
messages (300 octets) are transmitted at 500 microsecond 
intervals from the TS directed to the SS which SS redirects 
the message packets back to the TS. After starting NPT test 
Daemons on systems C and A (see FIG. 3) using executable 
script startnpt, provided in Appendix B, this test methodol- 
ogy is initiated on system C in accordance with executable 
test scripts entitled casel5d (delay) and caselSnd (no delay), 
with example scripts being provided in Appendix B. The 
packet delay results incurred for the example tests of mea- 
suring the round trip times for messages traversing this path 
according to these example test scripts are recorded such as 
shown in FIG. 9(6) (with delay) and 9(c) (without delay). 

FIG. 10(a) illustrates the logical test configuration for the 
FEDS-GIGAswitch-Cisco 7513-BPX-BPX-Cisco 7513- 
GIGAswitch-Remote FEDS connectivity path for verifying 
successful packet transfer from a FEDS server to a BEDS 
server over the FDDI, with no extraneous routes, using 
subnet 3 (IP_ 3) (provisioning traffic). According to one 
embodiment of the FEDS-GIGAswitch-Cisco 7513-BPX- 
BPX-Cisco 7513-GIGAswitch-Remote FEDS benchmark 
test methodology of the invention, 100 messages are trans- 
mitted at 1 second intervals from the FEDS directed to the 
BEDS which returns the packets to the originating FEDS. 
After starting NPT test Daemons on systems F and A (see 
FIG. 3) using executable script startnpt, this test methodol- 
ogy is initiated on system C in accordance with executable 
test scripts entitled casel6d (delay) and casel6nd (no delay), 
with example scripts being provided in Appendix B. FIGS. 
10(6) and 10(c) illustrate the packet delay results incurred 
when measuring the round trip times from the FEDS- 
Remote FEDS with a delay option (FIG. 10(6)) and without 
the delay option (FIG. 10(c)) according to these example test 
scripts. 

FIG. 11(a) illustrates the logical test configuration for the 
SS-GIGAswitch-Cisco 7513-BPX-BPX-Cisco 7513- 
GIGAswitch-RS connectivity path for verifying successful 
packet transfer from the SS to the RS over the WAN using 
subnet 4 (IP_4). According to one embodiment of the 
SS-GIGAswitch-Cisco 7513-BPX-BPX-Cisco 7513- 
GIGAswitch-RS benchmark test methodology of the 
invention, 10 messages of 7 Mbytes each, for example, arc 
transmitted at 10 second intervals from the SS to the RS 
which redirects the messages back to the SS. After starting 
NPT test Daemons on systems F and A (see FIG. 3) using 
executable script startnpt, this test methodology is initiated 
on system A in accordance with executable test scripts 
entitled casel7d (delay) and casel7nd (no delay), with 
example scripts being provided in Appendix B. FIGS. 11(6) 
and 11(c) illustrate the packet delay results incurred when a 
test is run with a delay option (FIG. 11(6)) and without the 
delay option (FIG. 11(c)) according to these example lest 
scripts. 

Further path validation and latency benchmark testing 
includes a test for verifying the impact of flooding the Call 
Processing LAN with real-time traffic (High load LAN 
latency, R/T traffic). For this test, reference is further made 
to the CS-CPFR-TS test connectivity path illustrated in FIG. 
S(a). According to one embodiment of the CPFR LAN 
real-time high load traffic benchmark test methodology of 
the invention, 10,000 (204 byte) messages at 1 microsecond 
intervals are transmitted to the target system with the round 
trip times for example messages traversing this path 
recorded. Particularly, after starting NPT test Daemons on 
systems E and D (see FIG. 3) using executable script 
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startnpt, as provided in Appendix B, this test methodology is 
initiated on system E in accordance with test scripts entitled 
caselSd (delay) and casel8nd (no delay), the example 
scripts being provided in Appendix B. FIGS. 12(a) and 12(6) 
illustrate the path latency (measured in ms) results when the 
example tests are run with a delay option (FIG. 12(a)) and 
without the delay option (FIG. 12(6)) according to these 
example test scripts. Successful performance criteria for this 
lest includes receiving messages with latencies less than a 
predetermined timeout window. 

Another benchmark test includes a test for verifying the 
impact of flooding the Provisioning LAN with provisioning 
traffic (High load LAN latency, Provisioning traffic). For this 
test, reference is made to the TS-PFR-GIGAswitch-SS test 
connectivity path illustrated in FIG. 9(a). According to one 
embodiment of the PFR LAN high load provisioning traffic 
benchmark test methodology of the invention, 10,000 2,040 
byte messages at 1 microsecond intervals arc transmitted to 
the target system with the round trip times for example 
messages traversing this path recorded. Particularly, after 
starting NPT test Daemons on systems C and A (see FIG. 3) 
using executable script startnpt, this test methodology is 
initiated on system C in accordance with executable test 
scripts entitled casel9d (delay) and casel9nd (no delay), 
with example scripts being provided in Appendix B. Suc- 
cessful performance criteria for this test includes receiving 
messages. FIGS. 13(a) and 13(6) illustrate the path latency 
(measured in ms) results for the LAN High Load provision- 
ing traffic tests with a delay option (FIG. 13(a)) and without 
the delay option (FIG. 13(6)) according to these example test 
scripts. It is understood that as long as messages are 
received, the test is considered successful. 

Further benchmark testing includes a test for verifying the 
impact of flooding the WAN with real-time traffic (High load 
WAN latency, R/T traffic). For this test, reference is made 
only to the ATS to GDS portion of the CS-CPFR-TS -CPFR- 
ATS-CPFR-Cisco 7513 FDDI-Cisco 7513 ATM-BPX-BPX- 
Cisco 7513 ATM-Cisco 7513 FDDI-CPFR-GDS (remote) 
connectivity path illustrated in FIG. 8(a). According to one 
embodiment of the WAN High Load R/T benchmark test 
methodology of the invention, 10,000 (204 byte) messages 
at 1 microsecond intervals are transmitted to the target 
system with the round trip times for example messages 
traversing this path recorded. Particularly, after starting NPT 
test Daemons on systems C and T (see FIG. 3) using 
executable script startnpt, this test methodology is initiated 
on system C in accordance with executable test scripts 
entitled casellOd (delay) and casellOnd (no delay), with 
example scripts being provided in Appendix B, FIGS. 14(a) 
and 14(6) illustrate the path latency results for the PFR WAN 
Real-Time High Load provisioning traffic tests when run 
with a delay option (FIG. 14(a)) and without the delay 
option (FIG. 14(6)) according to these example test scripts. 
Successful performance criteria for this test includes receiv- 
ing messages with latencies less than a predetermined tim- 
eout window. 

Another benchmark test includes a test for verifying the 
impact of flooding the Provisioning WAN with provisioning 
traffic (High load WAN latency, Provisioning traffic). For 
this test, reference is made to the FEDS-GIGAswitch-Cisco 
7513-BPX-BPX-Cisco 7513-GIGAswitch-Remote FEDS 
connectivity path illustrated in FIG. 10(a). According to one 
embodiment of the WAN High Load Provisioning traffic 
benchmark test methodology of the invention, 10,000 2,040 
65 byte messages are transmitted at 1 microsecond intervals to 
the target system with the round trip times for example 
messages traversing this path recorded. Particularly, after 
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starting NPT test Daemons on systems F and A (see FIG. 3) with multiple, e.g., four GeoLAN Hubs (two FDDI 

using executable script startnpt, this test methodology is interfaces) 410a, . . . ,41(W. The testing involves utilizing a 

initiated on system A in accordance with executable test script to enable the NFT tool to set up multiple transfers, first 

scripts entitled casellld (delay) and caselllnd (no delay), split between two physical interfaces, and then the same 

with example scripts being provided in Appendix B. FIGS. 5 transfers through a single interface. A "Vmstat" utility is 

15(a) and 15(b) illustrate the path latency results for the t0 collect performance data during the NFT test run. 

WAN Real-Time High Load provisioning traffic tests with a According to the Dual NIC Impact test, the following 

delay option (FIG. 15(a)) and without the delay option (FIG. parameters are observed on the TS system 402 during the 

15(b)) according to these example test scripts. Successful testing: a) throughput, in octets per second; b) total CPU 

performance criteria for this test includes receiving mes- 10 utilization on the AlphaServer from all sources; c) CPU 

sages, utilization by the system kernel of the AlphaServer; d) I/O 

Further benchmark testing includes a test for verifying the rates for the FDDI cards in the AlphaServer; and, e) latency 

impact of flooding the WAN with SS-RS traffic. For this test, across the FDDI rings (end to end across the workstations' 

reference is made to the SS-GIGAswitch-Cisco 7513-BPX- network stacks, including the NIC). 

BPX-Cisco 7513-GIGAswitch-RS connectivity path (subnet « According to the preferred embodiment, the guideline for 

I_4) illustrated in FIG. 11(a). According to one embodiment Dual NIC impact testing includes the following steps: Start 

of the WAN High Load SS-RS benchmark test methodology vmstat on all servers, and direct output to a file; send a range 

of the invention, 200 seven (7 Mbyte) messages are trans- Q f message rates to and from the AlphaServer 4100 simul- 

mitted at 1 microsecond intervals to the target system with tancously to and from two servers (Dual NIC Full-Duplex); 

the round trip times for example messages traversing this 20 an d send a range of message rates to and from both servers 

path recorded such as shown in FIG. 16(a) and 16(6). to the AlphaServer 4100 (Dual NIC-Transmit and Receive). 

Particularly, after starting NPT test Daemons on systems A Traffic between server A and the AlphaServer 4100 may be 

and F (see FIG. 3) using executable script startnpt, provided 200 octets of application data (+IP overheads)— for simu- 

in Appendix B, this test methodology is initiated on systems i at i ng rea l-time traffic in the NIP configuration, and, traffic 

A in accordance with executable test scripts entitled ^ between server B and the AlphaServer 4100 may be a 

easel 12d (delay) and caseU2ud (no delay), with example mixture of 200 octet messages and the maximum message 

scripts being provided in Appendix B. FIGS. 16(a) and 16(6) s ^ w hich IP supports for simulating non-real-time traffic 

illustrate the path latency results incurred for the WAN ( e . g . call plan downloads). Message rates may range from 

Statistics High Load traffic tests with a delay option (FIG. i ow i oa d U p to and beyond the maximum designed call 

16(a)) and without the delay option (FIG. 16(6)). 30 processing capacity. Preferably, the tests are run for approxi- 

A further benchmark test is provided for the purpose of mately 10 minutes each with five iterations of each test being 

demonstrating the performance of real-time packets between run, in order to provide a confidence level for the test results, 

the ATS and (remote) GDS across the real-time PVC, while p or a Qua] NIC Transmit (High Load) test case scenario 

the provisioning and statistics PVCs are fully loaded. This me following steps are performed: Referring to FIG. 3, 

represents a worst-case loading for the systems, routers and server B is first connected to the GeoLAN FDDI hub P; a 

PVCs in the network of FIG. 2. The configuration for this vmstat script stat541 provided in Appendix B, is initiated on 

WAN real-time, provisioning and statistics ultra high load system C for directing the output to a file. The NPT daemons 

test is depicted as the ATS to remote GDS portion of FIG. are then started on systems B, C and D using script startnpt. 

8(a). For this test case, five servers were implemented, three Then, the script case541txhigh is started on system C which 

servers of which functioning to send provisioning traffic script ^ prov ided in Appendix B. After about ten (10) 

(2040 byte messages), real lime traffic (204 byte messages) minutes, in a preferred embodiment, the npt is stopped on 

and statistics traffic (7 Mb messages) simultaneously. One system C. 

the WAN to two target servers one to receive the provi- me followi are Re ' ferrin to RG . 3 , 

stoning and real-time data, the other to receive the statistics ^ fi fc ^ to me GeoLAN FDDI hub P; a 

data. A successful performance measure of this case is that vmstat script stat542, provided in Appendix B, is initiated on 

no packets are lost, and real-time packet latency is unaf- system C for directing the output toa file. The NPT daemons 

T r r ^otTv?' ^ & ? ' P rov ? lonm S ™? arc then started on systems b" C and D using script startnpt. 

sutistics BPX PVCs may be monitored at levels up to 70% ^ ^ fl ^ case5 ; 2rxhighp ^ started 0Q %J m B J, 

utilized, witn no data loss. case542rxhighc is started on system D by coordinated 

Dual NIC Cards console actions. After about ten (10) minutes, in a preferred 

As mentioned above, a critical benchmark test includes embodiment, the npt is stopped on systems B and D. 

the Dual NIC Impact test for testing the impact of dual FDDI p or a Dua] njc Full Duplex (High Load) test case 

NIC cards in an ATS system, i.e., measuring the effect on 55 scenario the following steps are performed: Referring to 

system resources of adding a second FDDI interface to an fig. 3, server B is first connected to the GeoLAN FDDI hub 

alpha system. According to the invention, the Dual NIC p ; a vmstat ^pi s tat543, provided in Appendix B, is 

Impact test is configured to verify the following: a) that dual initiated on system C for directing the output to a file. The 

homing onto two double FDDI rings simultaneously works NPT daemons are then started on systems B, C and D using 

(i.e., may send/receive messages from both FDDI rings at ^ ^p, startnpt. Then, a script case543fdhighp is started on 

the same time); b) verify the benchmark CPU overhead sys tem B and a script case543fdhighc is started on system D 

(dual vs single FDDI NIC); and, c) verify the benchmark I/O by coordinated console actions. After about ten (10) 

overhead (dual vs single FDDI NIC). minutes, in a preferred embodiment, the npt is stopped on 

FIG. 17 illustrates the logical test configuration 399 for systems B and D. Preferably, the dual NIC procedure is 

the Dual NIC Impact test according to the preferred embodi- 65 repeated several times, e.g., three times, at each of three 

ment of the invention. As shown in FIG. 17, a transaction packet output rates: 2K output (4K total I/O), 4K output (8K 

server (TS) 402, e.g., DEC AlphaServer 388 is interfaced total I/O), and 6K output (12K total I/O). 
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Failover/Failback messages of 204 octets once per millisecond, using the UDP 

As mentioned above, a critical benchmark test includes protocol. Particularly, the test is as follows: in a first step, 

the failover/failback tests for determining failover and fail- hubs P and Q are disconnected from the GIGAswitch (FIG. 

back times for each single component failure. The configu- 3). Next, servers B and C are dual home connected to hubs 

ration for these sets of tests are similar to the benchmark 5 P and Q, ensuring the B port for servers B and C goes to hub 

topology for the LAN path and latency tests. In the LAN P. Then, nptd test script startnptdudp is then started (in UDP 

path and latency tests, the goal was to check if the traffic was mode) on servers B and C such as provided in Appendix B. 

using the expected routes. In the failover and failback tests, Then script caseSUl is executed on server B for generating 

the aim is to measure failover times for each communica- a stream of 100 messages/second, for example. Then, hub P 

tions component. Successful failover/failback criteria are 10 is powered down five (5) seconds after starting script 

based on parameters including response times (before, case5111. After 10 seconds, the npt tool is stopped on server 

during, and after failover), failover time to backup device, B. Finally, a "ps" (process status) command is performed 

failback times from failback device to newly recovered that requests a list of all processes running on the systems, 

primary device. Additionally, the effect on link status and This list is then piped to a "grep" command, (Get Regular 

routing may be monitored. Absolute success is determined :s Expression), which looks for lines containing the string npt, 

by the observed data. For example, failover recovery times and prints those lines to screen. These lines contain the 

exceeding two (2) seconds is deemed excessive. Any detri- process ID. Then, the process ID taken from the previous 

mental effect on LAN/WAN routing capability, e.g., the step is terminated, without recourse by the process, by 

inducement of unacceptable routes in failure recovery executing a kill command. 

attempts, is additionally deemed unacceptable. 20 In an example test run, the net effect of the failover 

In the preferred embodiment, the failover and failback resulted in no messages being lost. However, several mes- 

tests are structured so that each single communications sages were delayed, e.g., starting with a 25 millisecond 

component is failed in turn with each failed component delay on the first message, with subsequent messages' 

being brought back into service to measure failback times. delays shortening in a linear fashion to the normal latency 

The components targeted for failure include: the GeoLAN 25 period. 

hub to GeoLAN hub; the Gigaswitch (use the data from the For the second test case, an interface disconnect failure is 

IP testing); the GIGAswitch to GeoLAN link; and, the 7513 implemented as the primary GeoLAN to the backup 

router. Particularly, for the test scenarios, a constant stream GeoLAN failure, e.g., by removing the "B" port connection 

of real-time traffic is provided between two (2) of these to the receiving server on the primary hub and inducing 

components and the impact of failover and failback on 30 failback after the initial failover recovery. The NPT tool is 

response times is measured when a component is failed. configured to send real-time messages of 204 octets once per 

Afiistsetof tests is devised to measure failover to backup millisecond, for example, using the UDP protocol, 

performance including: 1) a failure from the primary Particularly, the test is as follows: in a first step, hubs P and 

GeoLAN to the backup GeoLAN under message loading of Q are disconnected from the GIGAswitch (FIG. 3). Next, 

100 messages per second; 2) a failure from the primary 35 servers B and C are dual home connected to hubs P and Q, 

GIGAswitch to the backup GIGAswitch under message ensuring the B port for servers B and C goes to hub P. Then, 

loading of 100 messages per second; 3) a failure from the the nptd test daemon is started (in UDP mode) on servers B 

primary GIGAswitch to GeoLAN link to the backup and C implementing the script startnptdudp such as provided 

GIGAswitch to GeoLAN link under message loading of 100 in Appendix B. Then script case5112 is executed on server 

messages per second; and, 4) a failure from the primary 40 B for generating a stream of 100 messages/second, for 

Cisco 7513 router to the backup Cisco 7513 router under example. Then, port "B" is disconnected on hub P connected 

message loading of 100 messages per second. to server B five (5) seconds after starting script case5112. 

A second set of tests is devised to measure failback to After 10 seconds, the npt tool is stopped on server B. Finally, 

primary performance including: 1) a failure from the pri- the above-described "ps" (process status), "grep" command, 

mary GeoLAN to the backup GeoLAN under message 45 and kill commands are executed. 

loading of 100 messages per second, and, after recovery of For the next series of cases in this first test set, primary 
the primary system, failback to the primary; 2) a failure from GIGAswitch to backup GIGAswitch failover performance is 
the primary GIGAswitch to the backup GIGAswitch under tested. For the first test case, a switch power failure is 
message loading of 100 messages per second and, after induced Particularly, the test is as follows: in a first step, 
recovery of the primary system, failback to the primary; 3) so servers A and B are dual home connected to switches J and 
a failure from the primary GIGAswitch to the GeoLAN link K, ensuring the B port for each server A and B goes to switch 
to the backup GIGAswitch to GeoLAN link under message J. Next, the nptd test daemon is started (in UDP mode) on 
loading of 100 messages per second, and then failback; and, servers A and B using script startnptdudp such as provided 
4) a failure from the primary Cisco 7513 router to the backup in Appendix B. Then, script case5121 is executed on server 
Cisco 7513 router under message loading of 100 messages 55 B for generating a stream of 100 messages/second, for 
per second, and, after recovery of the primary system, example. Then, switch J is powered down about five (5) 
failback to the primary. seconds after starting the case5121 script. After 10 seconds, 
With respect to the first set of tests for measuring failover the npt tool is terminated on server B. Finally, the above- 
to backup performance, a first test case is implemented for described "ps" (process status), "grep" command, and kill 
testing primary GeoLAN to the backup GeoLAN failover 60 commands are executed. 

performance. For this first test case, a hub power failure is For the next test case, primary GIGAswitch to backup 

implemented as the primary GeoLAN to the backup GIGAswitch failover performance is tested when inducing 

GeoLAN failure, e.g., by removing power to the GeoLAN. an interface disconnect failure while the NPT tool is con- 

The net effect of this failover is to fail the hub and the figured to send real-time messages using the UDP protocol, 

interfaces on the servers. The hardware setup comprises two 65 Particularly, in a first step, servers A and B are dual home 

Alphaservers and two GeoLAN hubs (reference is had to connected to switches J and K, ensuring the B port for each 

FIG. 3). The NPT tool is configured to send real-time server A and B goes to hub P. Then, the nptd test daemon is 
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started (in UDP mode) on servers A and B implementing the step, the nptd test daemon is started (in UDP mode) on 

script startnptdudp. Then script case5122 is executed on servers A and E using script startnptdudp (See Appendix B). 

server B for generating a stream of 100 messages/second, for Next, script case5l42 is executed on server A for generating 

example. Then, port "B" is disconnected from switch J a stream of 100 messages/second, for example. Then, both 

connected to server B five (5) seconds after starting script 5 FDDI ports on the primary router H are disconnected about 

casc5122. After 10 seconds, the npt tool is stopped on server five about (5) seconds after starting script, and, after about 

B. Finally, the above-described "ps" (process status), "grep" 30 seconds, the npt tool is terminated on server A Finally, 

command, and kill commands are executed. the "ps" (process status), "grep" command, and kill com- 

For the next series of cases in this first test set, primary mands are executed. 

GIGAswitch to GcoLAN Link to Backup GIGAswitch to 10 With respect to the second set of tests for measuring 

GeoLAN Link failover performance is measured. For the fallback to primary performance, a first series of test cases 

first test case of this series, a switch power failure is induced is implemented for testing primary GeoLAN to the backup 

by removing power to the switch. Particularly, the test is as GeoLAN failure and failback. In a first series of tests, a hub 

fallows: in a first step, server B is dual home connected to power failure is induced, e.g., by removing power to the 

switches J and K, ensuring the B port for server B goes to 15 GeoLAN and, a recovery is implemented by again powering 

switch J. It is additionally ensured that the A and B ports on up the hub. For the first test case, reference is had to FIG. 3. 

hubs P and Q are connected to M ports on GIGAswitches J In a first step, hubs P and Q are disconnected from the 

and K. Next, the nptd test daemon is started (in UDP mode) GIGAswitch and, servers B and C are dual home connected 

on servers B and C using script startnptdudp. Then, script to hubs P and Q, ensuring the B port for each server B and 

case5131 is executed on server B for generating a stream of 20 C goes to hub P. Next, the nptd test daemon is started (in 

100 messages/second, for example. Then, switch J is pow- UDP mode) on servers B and C using script startnptdudp and 

ered down about five (5) seconds after starting the case5131 script case5211 is executed on server B for generating a 

script. After 10 seconds, the npt tool is terminated on server stream of 100 messages/second, for example. Then, the hub 

B. Finally, the above-described "ps" (process status), "grep" P is powered down about five (5) seconds after starting the 

command, and kill commands are executed. 25 case5211 script. After about 10 seconds thereafter, hub P is 

For the next test case, primary GIGAswitch to GeoLAN powered up and, after about 15 seconds thereafter, hub Q is 
Link to Backup GIGAswitch to GeoLAN Link failover powered down. Then, about 10 seconds after powering 
performance is measured when inducing an interface dis- down hub Q, the npt tool is terminated on server B. Finally, 
connect failure. Particularly, the test is as follows: in a first the "ps" (process status), "grep" command, and kill corn- 
step, server B is dual home connected to switches J and K, 30 mands are executed. 

ensuring the B port for server B goes to switch J. It is For the next test case, primary GeoLAN to the backup 

additionally ensured that the A and B ports on hubs P and Q GeoLAN failure and failback performance is tested when 

are connected to M ports on GIGAswitches J and K, Next, inducing an interface disconnect, e.g., by removing the "B" 

the nptd test daemon is started (in UDP mode) on servers B port connection to the receiving server on the primary hub 

and C using script startnptdudp. Then, script case5132 is 35 and, executing recovery. Particularly, the test is as follows: 

executed on server B for generating a stream of 100 in a first step, hubs P and Q are disconnected from the 

messages/second, for example. Then, the B port is discon- GIGAswitch (FIG. 3). Next, servers B and C are dual home 

nected from switch J connected to GeoLAN P about five (5) connected to hubs P and Q, ensuring the B port for servers 

seconds after starting the case5132 script. After 10 seconds, B and C goes to hub P. Then, the nptd test daemon is started 

the npt tool is terminated on server B. Finally, the above- 40 (in UDP mode) on servers B and C implementing the script 

described "ps" (process status), "grep" command, and kill startnptdudp. Then, script case5212 is executed on server B 

commands are executed. for generating a stream of 100 messages/second, for 

For the next series of cases in this first set, primary Router example. Then, the port "B" connected to server B is 

to backup Router failover performance is measured. In a first disconnected from hub P about five (5) seconds after starting 

test case of this series, a router power failure is induced. 45 script case5212. After about 10 seconds thereafter, the port 

Particularly, in a first step, the nptd test daemon is started (in B is reconnected on hub P connected to server B and, after 

UDP mode) on servers A and E using script startnptdudp. about 15 seconds thereafter, the port B is disconnected on 

Next, a script case5141 is executed on server A for gener- hub Q connected to server B. Then, about 10 seconds after 

ating a stream of 100 messages/second, for example. Then, that, the npt tool is terminated on server B. Finally, the "ps" 

the primary router H is powered down five about (5) seconds 50 (process status), "grep" command, and kill commands are 

after starting the script case5141, and, about 30 seconds executed. 

thereafter, the npt tool is terminated on server A Finally, the In an example test run, a first failure caused approxi- 

above-described "ps" (process status), "grep" command, mately 240 messages to be lost during the failover, and, on 

and kill commands are executed. recovery, the next 107 messages are delayed, with the first 

In an example failover test run, for example, a UDP 55 message delayed by approximately 250 ms with subsequent 

packet stream is sent from the blssOl server round trip to a messages being delayed by shortening time periods. The 

distant system via the Cisco 7513 routers (FIG. 3). The amount of delay shortens in a linear fashion to the normal 

routers were set up using HSRP as the failover mechanism. latency period. 

The primary router was then powered off. The characteris- For the next series of cases, primary GIGAswitch to 

tics of the failovers on the routers due to power loss include: 60 backup GIGAswitch failover and failback performance is 

calculation of event duration from the start of the buffer loss, tested. In a first case, performance is measured when a 

e.g., at one millisecond per buffer, to the end of the buffer switch power failure and recovery is induced. This case 

delay period, where the delay returns to the nominal delay entails, dual home connecting servers A and B to switches J 

value. and K, ensuring that the B port for servers A and B goes to 

For the next test case, primary Router to backup Router 65 switch J. Then, the nptd test daemon is started (in UDP 

failover performance is measured when inducing an inter- mode) on servers A and B implementing the script startnpt- 

face disconnect failure at the router. Particularly, in a first dudp and, script case5221 is started on server A for gener- 
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a ling a stream of 100 messages/second, for example. Next, 
switch J is powered down about five (5) seconds after 
starting script case5221. Then, after 10 seconds, the 
GIGAswitch J is powered up. After about 15 seconds, 
GIGAswitch K is powered down. Then, about 10 seconds 
after that, the npt tool is terminated on server A. Finally, the 
"ps" (process status), "grep" command, and kill commands 
are executed. 

In an example test run, no messages were lost during the 
failover test run. However, for the case of failover/failback, 
a series of test runs proved out that on recovery, all delays 
of subsequent messages shorten in a linear fashion to the 
normal latency period. 

For the next test case, primary GIGAswitch to backup 
GIGAswitch failover and fallback performance is tested 
when performing an interface disconnect and executing 
recovery. In a first step, servers A and B are dual home 
connected to switches J and K (FIG. 3), ensuring the B port 
for servers A and B is connected to switch J. Then, the nptd 
is started in UDP mode on servers A and B by using script 
startnptdudp and script case5222 is started on server A for 
generating a stream of 100 messages/second, for example. 
Next, the B port on switch J connected to server A is 
disconnected about five (5) seconds after starting script. 
After about 10 seconds, the B port is reconnected on switch 
J connected to server A. Then, after 15 seconds, the B port 
is disconnected on switch K connected to server A, and after 
10 seconds, the tool is stopped on server A. Finally, the "ps" 
(process status), "grep" command, and kill commands arc 
executed. 

For the next series of cases, primary GIGAswitch to 
GeoLAN Link to backup GIGAswitch to GeoLAN Link 
failover and failback performance is tested. For the first case 
of this series, performance is measured when a switch power 
failure is induced. For this test, server B is dual home 
connected to switches J and K, ensuring the B port for server 
B goes is connected to switch J. It is additionally ensured 
that the A and B ports on hubs P and Q are connected to M 
ports on GIGAswitches J and K. Then, the nptd is started in 
UDP mode on servers B and C by using script startnptdudp 
and script case5231 is started on server B for generating a 
stream of 100 messages/second, for example. Then, switch 
J is powered down 5 seconds after starting script case5231. 
After about 15 seconds, switch J is powered up and about 15 
seconds thereafter, switch K is powered down. Then, the npt 
tool is stopped on server B after about 10 seconds thereafter. 
Finally, the "ps" (process status), "grep" command, and kill 
commands are executed. 

For the next test case of this series, primary GIGAswitch 
to GeoLAN Link to backup GIGAswitch to GeoLAN Link 
failover and fallback performance is tested when performing 
an Interface Disconnect. In a first step, server B is dual home 
connected to switches J and K, ensuring the B port for 
servers B and C goes to switch J. It is additionally ensured 
that the A and B ports on hubs P and Q are connected to M 
ports on GIGAswitches J and K. Then, the nptd is started in 
UDP mode on servers B and C by using script startnptdudp 
and script case5232 is started on server B for generating a 
stream of 100 messages/second, for example. Then, the M 
port on switch J connected to GeoLAN P is disconnected 
about five (5) seconds after starting the script case5232. 
After about 15 seconds, the M port on switch J is recon- 
nected and, about 15 seconds thereafter, the M port on 
switch K connected to GeoLAN P is disconnected. Then, the 
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npt tool is stopped on server B after about 10 seconds 
thereafter. Finally, the "ps" (process status), "grep" 
command, and kill commands are executed. 

For the next series of cases, Primary Router to Backup 
Router failover and failback performance is tested. For the 
first case of this series, performance is measured when a 
router power failure and recovery is induced. In a first step, 
the nptd is started in UDP mode on servers A and £ (FIG. 3) 
by using script startnptdudp and script case5241 is started on 
server A for generating a stream of 100 messages/second, for 
example. Then, the primary router H is powered down 5 
seconds after starting script case5241. After about 30 
seconds, router H is powered up and about 30 seconds 
thereafter, router I is powered down. Then, the npt tool is 
stopped on server A about 30 seconds thereafter. Finally, the 
"ps" (process status), "grep" command, and kill commands 
are executed. 

For the next test case, Primary Router to Backup Router 
failover and failback performance is tested by performing an 
Interface Disconnect. In a first step, the nptd is started in 
UDP mode on servers A and E (FIG. 3) by using script 
startnptdudp and script case5242 is started on server A for 
generating a stream of 100 messages/second, for example. 
Then, both FDDI ports on the primary router H are discon- 
nected about five (5) seconds after starting script case5242. 
After about 30 seconds, the FDDI ports to router H are 
reconnected. Then, after about 15 seconds, both FDDI ports 
on router I are disconnected. After 15 seconds, the npt tool 
on server A is terminated. Finally, the "ps" (process status), 
"grep" command, and kill commands are executed. 

In an example failover/failback test run, an UDP packet 
stream is sent from the blssOl server (FIG. 3) round trip to 
a distant system via the Cisco 7513 routers. The routers are 
set up using HSRP as the failover mechanism. The primary 
router then had the FDDI interface disconnected. The result- 
ing characteristics of the failovers and failback on the 
routers due to interface loss include a measurement of the 
event duration from the start of deviation from the nominal 
latency to the recovery to the nominal latency by the total 
number of delayed buffers, e.g., when transmitted at one 
millisecond intervals. 

The novel benchmark testing methodology described 
herein fully proves out the performance benefits, resiliency 
and redundency designed into the NIP LAN/WAN of the 
invention. Functionally, the benchmark configuration and 
test described herein proves that the LAN/WAN design of 
the invention successfully segments the various traffic types, 
both within the LAN, and across the WAN. Further, it has 
been demonstrated that performance of the real-time traffic, 
including the cross WAN ATS-GDS traffic, is unaffected by 
provisioning and statistics traffic. Real time packet latencies 
(all latencies are measured as round-trip) across the WAN 
are proven to be approximately in the 1.6 ms range, regard- 
less of other WAN traffic levels. This does not include WAN 
propagation delays which measure in the 10-14 ms range on 
the NIP production sites. Without traffic segregation 
afforded by the network topology of the invention, real-time 
packet latencies may increase above 7 seconds when the 
links are subject to heavy loads. 

The foregoing merely illustrates the principles of the 
present invention. Those skilled in the art will be able to 
devise various modifications, which although not explicitly 
described or shown herein, embody the principles of the 
invention and are thus within its spirit and scope. 
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APPENDIX A - IP Addressing 









blssOtOl 


Alpha A subnet I 


172.25.68.34 


blss0102 


Alpha A subnet 2 


172.25.68.69 


blss0103 


Alpha A subnet 3 


172.25.68.98 


blss0104 


Alpha A subnet 4 


172.25.68.130 


blrsOI03 


Alpha B subnet 3 


172.25.68.99 


blrsOI04 


Alpha B subnet 4 


172.25.68.131 


blatOIOl 


Alpha C subnet 1 


172.25.68.35 


blat0102 


Alpha C subnet 2 


172.25.68.66 


blat0103 


Alpha C subnet 3 


172.25.68.100 


bltsOlOl (bltsOl) 


Alpha D subnet 1 


172.25.68.36 


blts0102 


Alpha D subnet 2 


172.25.68.67 


blcsOtOl (blcsOl) 


Alpha E subnet 1 




bl 6 d0102 


Alpha B subnet 2 (only if connected to 
hub R) 


172.25.68.68 


b2fe0102 


Alpha F subnet 2 


172.25.69.67 


b2fe0103 


Alpha F subnet 3 


172.25.69.98 


b2gd0101 


Alpha T subnet 1 


172.25.69.34 


b2gd0!02 


Alpha T subnet 2 


172.25.69.66 


b3ss0103 


Alpha T subnet 3 (only when 
configured to hub Q) 


172.2i.70.98 


b3ss0104 


Alpha T subnet 4 (only when 
configured to hub Q) 


172.25.70.129 


b2rtvi01 


Cisco 75)3 G FDDI 0 


172.25.69.33 


b2rtvi02 


Cisco 7513 G FDD! I 


172.25.69.65 


b2rtvi03 


Cisco 7513GFDDJ2 


172.25.69.97 


b2rtvi04 


Cisco 7513 G FDD! 2 


172.25.69.132 


blrtviOl 


Cisco 7513H FDDIO 


172.25.68.33 


blrtvi02 


Cisco 7513 HFDD1 I 


172.25.6S.65 


blrtvi03 


Cisco 7513HFDDI2 


172.25.68.97 


blrtvi04 


Cisco 751311 FDDI2 


172.25.68.132 


b3rtvi0t 


Cisco 75 13 1 FDD] 0 (only when 
separated from router H) 


172.25.70.33 


b3rtvi02 


Cisco 7513 I FDDI 1 (only when 
separated from router H) 


172.25.70.65 


b3rtvi03 


Cisco 7513 I FDDI 2(only when 
separated from router H) 


172.25.70.97 


b3rtvi04 


Cisco 75 13 1 FDDI 2(only when 
separated from router H) 


172.25.70.132 
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Benchmark Subnet Design 

IP Class: C IP Address: 172.25.68.0 

Mask Bits: 3 Subnet Mask: 255.255.255.224 

Subnets: 6+1 IP Major Net: 172.25.68.0 

Hosts/Subnet: 30 Major Net Broadcast: 172.25.68.255 



Don't use subnet 0 (unless using ip subnet-zero command) and subnet 7. 











'BroadcasfAddcessf: T;,'. 


0 


172.25.68.0 


172.25.68.1 


172.25.68.30 


17225.68.31 


1 


172.25.68.32 


172.25.68.33 


172.25.68.62 


172.25.68.63 


2 


172.25.68.64 


172.25.68.65 


172.25.68.94 


172.25.68.95 


3 


172.25.68.96 


172.25.68.97 


172.25.68.126 


172.25.68.127 


4 


172.25.68.128 


172.25.68.129 


172.25.68.158 


172.25.68.159 


5 


172.25.68.160 


172.25.68.161 


172.25.68.190 


172.25.68.191 


6 


172.25.68.192 


172.25.68.193 


172.25.68.222 


172.25.68.223 


7 


172.25.68.224 


172.25.68.225 


172.25.68.254 


172.25.68.255 



as 
\* 

3 Benchmark PVC Setup 









lytrtLial:; 


mm* 




;t A*Jlt5s • 


WW 


75"l3" 
router H 


ATM 0 


2xE3 


5.1 


40.801 


40.791 


172.25.69. 
161 


75 1 3 G ATM 0 PVC 1 


7513 
router H 


ATM 0 


2xE3 


6.1 


46.803 


40.792 


172.25.69. 
164 


7513 G ATM 0 PVC 2 


7513 
router H 


ATM 0 


2xE3 


7.1 


40.805 


40.797 


172.25.69. 
167 


75 13 G ATM 0 PVC 3 


7513 
router H 


ATM 6 


2xE3 


5.1 


40.807 


40.795 


172.25.69. 
170 


75131 ATM 0 PVC 1 
(not initial setup) 


7513 
router H 


ATM 0 


2xE3 


6.1 


40.809 


40.7% 


17^.25.69. 
173 


75 13 I ATM 0 PVC 2 
(not initial setup) 


7513 
router H 


ATM 0 


2xE3 


7.1 


40.811 


40.799 


172.25.69. 
176 


7513 1 ATM 0 PVC 3 
(not initial setup) 











mm- 










75131 
router 


ATM 0 


2xE3 


5.1 


40.815 


40.791 


172.25.69. 
162 


Cisco 75 1 3 G ATM 0 
PVC4 


7513 I 
router 


ATM 0 


2xE3 


6.1 


40.817 


40.792 


172.25.69. 
165 


Cisco 7513 G ATM 0 
PVC 5 
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Msg 














Deatl natkwi Dfivtco t ". 

Mil 


75131 
router 


ATM 0 


2xE3 


7.1 


40.819 


40.813* 


172.25.69. 
168 


Cisco 7513 G ATM 0 
PVC6 


75131 
router 


ATM 0 


2xE3 


5.1 


40.808 


40.793 


172.25.69. 
171 


Cisco 7513 H ATM 0 
PVC4 


7513 1 
router 


ATM 0 


2xE3 


6.1 


40.810 


40.794 


172.25.69. 
174 


Cisco 75 13 H ATM 0 
PVC5 


7513 1 
router 


ATM 0 


2xE3 


7.1 


40.812 


4Q.80b» 


172.25.69. 
177 


Cisco 75 13 H ATM 0 
PVC6 







liill 




pHK 


US 


mi 




Cisco 
7513 G 
router 


ATM 0 


2*E3 


5.1 


40.802 


40.793 


172.25.69. 
163 


Cisco 7513 H ATM 0 
PVC1 


Cisco 
7513 G 
router 


ATM 0 


2xE3 


6.1 


40.804 


40.794 


172.25.69. 
166 


Cisco H 7513 ATM 0 
PVC2 


Cisco 
7513 G 
router 


ATM 0 


2xE3 


10.1 


40.806 


40.798* 


172.25.69. 
169 


Cisco H 75 13 ATM 0 
PVC3 


Cisco 
7513 G 
router 


ATM 0 


2xE3 


5J 


40.816 


40.795 


172.25.69. 
172 


Cisco 7513 I ATM 0 
PVC 1 


Cisco 

7513G 

router 


ATM 0 


2xE3 


6.1 


40.818 


46.796 


172.25.69. 
175 


Cisco 7513 I ATM 0 
PVC 2 


Cisco 

7513G 

router 


ATM 0 


2xE3 


10.1 


40.820 


40.814* 


172.25.69. 
178 


Cisco 7513 I ATM 0 
PVC 3 
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etc/hosts File 



# hosts file for NIP2 benchmark testing 
ft 

# format of entries : 

# addr interface -name [host -name! 

# 1st site subnet 1 

172.25.68.33 blrtviOl 

172.25.68.34 blSsOlOl 

172.25.68.35 blatOlOl 

172.25.68.36 bltsOlOl bltsOl 

172.25.68.37 blcsOlOl blcsOl 



G5 



# 1st site subnet 2 

172.25.68.65 blrtvi02 

172.25.68.66 blat0102 

172.25.68.67 blts0102 

172.25.68.68 blgd0102 

172.25.68.69 blSS0102 

# 1st site subnet 3 

172.25.68.97 blrtvi03 

172.25.68.98 blss0103 

172.25.68.99 blrs0103 

172.25.68.100 blat0103 



blssOl 
blrsOl 
blatOl 



® 
D 

5 



# 1st site subnet 4 
172.25.68.132 blrtvi04 

172.25.68.130 blss0104 

172.25.68.131 blrs0104 

# 2nd site subnet 1 

172.25.69.33 b2rtvi01 

172.25.69.34 b2gd0101 

ft 2nd site subnet 2 

172.25.69.65 b2rtvi02 

172.25.69.66 b2gd0102 

172.25.69.67 b2fe0102 



b2gd01 



# 2nd site subnet 3 

172.25.69.97 b2rtvi03 

172.25.69.98 b2fe0103 



b2fe01 



# 2nd site subnet 4 
172,25.69.132 b2rtvi04 



# 3rd site subnet 3 
172.25.70.33 b3rtvi01 
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# 3rd site subnet 2 
172.25.70.65 b3rtvi02 

# 3rd site subnet 3 

172.25.70.97 b3rtvi03 

172.25.70.98 b3ss0103 b3ss01 

U 3rd site subnet 4 
172.25.70.132 b3rtvi04 
172.25.70.129 b3ss0104 
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APPENDIX B -Test Scripts 



G 

Si 
w 
M 

□ 

a 

m 

-js- 

W 

D 



startnpt 



/test/bin/nptd -p2001 -z -tl -d/test/data/20Cl . log 

/test/bin/nptd -p2002 -z -tl -d/test/data/2C02, log 

/test/bin/nptd -p2003 ~z -tl 

/test/bin/nptd -p2004 -z -tl 

startnptudp 

/tosL/bin/nptd -p2001 -2 -rO 

/test/bin/nptd -p2002 -z -rO 

startnptdelay 

/test/bin/nptd -p2005 -z -tO -d/test/data/2C01 .loq 

/test/bin/nptd -p2006 -z -tO -d/test/data/2C02.1og 

/test/bin/nptd -p2007 -z -tO 

/tesr/bin/nptd -p2008 -z -tO 



slay 

#!/bin/sh 

# kill all /test/bin/nptd lines 
ids-'ps -e I fgrep /test/bin/nptd 
for id in Sids 
do 

kill -30 $id 
done 



fgrep -v fgrepl awJc ' I print $ 



case lid 
»!/bin/ksh 

nr. /test/store/caselld.res 
touch /test/store/caselld.res 
/test/scripts/stnpt >> /test/store/caaellc. res 

npt -tO -hbltsOJ -p2C05 -hDlcsOl -p2005 -f/.est/data/rt.pay -nlOO 
110000 



easel 1 nd 



#!/bin/ksh 

rm /test/stcre/casel ind.res 
toucn /test/store/casellnd.res 
/test/scripts/stnpt » /test/store/casellnd. res 

npt -tl -hbltsOl -p2001 -hbicsOl -p2001 -f /Lest/data/rt . pay -nlOO 
ilOOOO 
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case i 2d 
i!/bin/ksh 

rra /test/store/casel2d.res 
touch /test/store/casel2d. res 
/test/scripts/stnpt » /test/store/casel2d. res 

npt -CO -hbltsOl -p2005 -hblat0102 -p200S -hblts0102 -p2006 -hblcsOl - 
p2006 -f/test/data/rt.pay -r.100 -ilOOOO 



caseUnd 
i!/bir.Ash 

rm /test/store/casel2nd. res 
touch /test/store/casel2nri.res 
/test/scripts/stnpt » /test/store/casel2r.d. res 

npt -tl -hbltsOl -p20Ol -h.blat0102 -p2001 -hblts0102 -p2002 -hblcsOlOl 
-p2002 -f/test/data/rt.pay -nlOO -i 10000 

® casel3d 

^ *!/bin/ksh 

& rm /test/store/casel3d. res 

iy touch /test/store/casel3d.res 

Q /test/scripts/stnpt » /test/3tore/cfisel3d. tes 

s npt -tO -hbltsOl -p2005 -hblat0i02 -p2005 -hblgdC102 -p2005 -hblat0102 

q -p2006 -hblts0102 -p2006 -hblcsOlOl -p2306 -f/test/data/rt.pay -nlOO - 

p ilOOOO 

h 

Q easel 3 nd 

♦!/bin/ksh 

rm /te3t/3tore/casel3.id. res 
touch /test/store/casel3nd. res 
/test/scripts/stnpt » /test/store/casel3nd.res 

npt -tl -hbltsOl -p2001 -hblat0102 -p2001 -hblgd0102 -p2001 -hblat0102 
-p2002 -hblts0102 -p2002 -hblcsOlOl -p2002 -f/test/data/rt.pay -nlOO - 
ilOOOO 



easel 4d 

ft !/bin/ksh 

rm /test/store/casei4d.res 
touch /test/score/caseHd.res 
/test/scripts/stnpt » /test/sccre/casel^d. res 
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npt -tO -hblrsOl -p2005 -hblat0102 -p2005 -hb2gd0102 -p20C5 -hblat0102 
-p2Q06 -hblts0102 -p2006 -hblcsOlOl -p20C6 -f/test/dat.a/rt.pay -nlOO - 
ilOOOO 



caseHnd 
ft ! /bin/ksh 

rm /test/store/casei4nd. res 
touch /test/store/caseUnd.res 

/test/scripts/stnpt >> /test/store/caselflr.d. res 

npt -tl -hbltsOl -p2001 -hblat01Q2 -p20Cl -hb2gd0102 -p2001 -hblat0102 
-p2002 -hblts0102 -p2002 -hblcsOlO". -p2002 - f/test/data/rt . pay -nlOO - 
ilOOOO 



case J Sd 
#!/bin/ksh 

rm /te3t/store/ca3el5d.res 
touch /test/store/case!5d. res 
/test/scripts/stnpt » /tesr/store/casel=d. res 

npt -tO -hblss01O3 -p2005 -hblat0103 -p2006 -f/test/data/prcv .pay -nlOO 
-ilOOOO 



easel 5 nd 
t! /bin/ksh 

rm /test/atore/caselSnd.res 
touch /test/store/casel5nd. res 
/test/scripts/stnpt » /Test/atcre/caselSnd. res 

npt -tl -hblss0103 -o2001 -hblat0103 -p2002 -t/test/data/prov.pay -nlQQ 
-ilOOOO 



caseI6d 
#! /bin/ksh 

rm /test/store/casel6d. res 
touch /test/store/casel6d.res 
/test/scripts/stnpt >> /test/atore/casel6d. res 

npt -tO -hb2fe0103 -p2005 -hblss0103 -p2006 -f /test/data/prov.pay -nlOO 
-ilOOGCOO 



casel6nd 
8! /bin/ksh 

rm /te3t/stoce/casel6nd.res 
touch /test/store/casel6nd.res 
/test/scripts/stnpt » /test/store/casel6nd. res 
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npt -tl -hb2fe0103 -p2C01 -hblss0103 -p2002 -f /test/data/prov.pay -nlOO 
-ilOOOOOO 



case J 7d 
•!/bin/ksh 

rm /test/atore/caselTd. res 
touch /cest/3tcire/casel7d.res 
/test/scripts/stnpt >> /test/3tore/casel7d. res 

npt -tO -hb2fe0104 -p2005 -hblssOlO* -p2006 -f/'est/data/TrnD .pay -r.10 - 
ilOOOOOOO 



easel 7nd 
ti/bin/ksh 

rm /test/store/casel7nd. res 
touch /test/store/casel7nd.res 
/test/scripts/stnpt » /test/store/casel7nd.res 

npt -tl -hb2ss0104 -p2001 -hblssOlOfl -p2002 -f/test/data/?mb.pay -nlO - 
ilOOOOOOO 



easel Bd 
#!/bin/ksh 

rm /test/store/casei8d. res 
touch /test/store/casel9d.res 
/test/3cript3/3tnpt » /test/store/casel8d. res 

npt -tO -hbltsOl -p2005 -hblat0102 -p2C05 -hblqc0102 -p2305 -hblat0102 
-p2006 -hblts0102 -p2006 -hblcsOlOl -p2006 -f/test/data/rt .pay -nlOOOO 
-il 



case I find 
#!/bin/ksh 

rra /teat/store/caselSnd. res 
touch /test/store/casel8nd. res 

/test/scripts/stnpt » /test/store/casol8nd . rea 

npt -tl -hbltsOl -p2001 -hblat0102 -p2001 -hblgd0102 -p2001 -hblat0102 
-p2002 -hblts0102 -p2002 -hbicsOlOl -p2002 -f /test/data/rt.pay -nlOOOO 
-il 



easel 9d 
*!/bin/ksh 

rm /test/store/ca3el9d.res 
touch /test/store/casel9d.re3 
/te3t/scripts/stnpt >> /test/store/casel9d. res 
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npt -tO -hblss0103 -p2305 -hblat0103 -p2006 -£ /lest/data/prov.pay - 
nlOOOO -il 



caseI9nd 
#!/bin/ksh 

rm /test/store/casel9r.d. res 
touch /test/store/casel9nd. res 
/test/scripts/stnpt » /test/store/caselSnd. res 

npt -tl -hbiss0103 -p2001 -hblat0l03 -p2002 -f/test/dara/prov.pay - 
nlOOOO -il 



easel I Od 
#!/bin/ksh 

rm /test/atore/casellOd.res 
touch /test/store/casellOd. res 
/test/scripts/atr.pt » /cesc/store/caseilOd. res 

npt -tO -hbltsOl -p2005 -hblat0102 -p20O5 -hblgd0102 -p2CC5 -hblat0102 
-p2006 -hblts0102 -p20C6 -hblcsOlOl -p2006 -f /test/data/rt -pay -nlOOOO 
-il 



easel lOnd 
8!/bin/icsh 

rm /test/store/casellOnd. res 
touch /test/atore/casel ICnd. res 
/test/scripts/stnpt >> /test/store/casellOnc. res 

npt -tl -hbltsOl -p2001 -hb".at0102 -p2001 -fcb:gd0102 -p2001 -hblat0102 
-p2O02 -hblta0102 -p2002 -hblcsOlOl -p2002 -f/test/data/rt .pay -nlOOOO 
-il 



easel) id 
# ! /bin/ksh 

rm /test/store/casellld. res 
touch /test/atore/casellld. res 
/test/scripts/stnpt » /test/store/casel lid. res 

npt -tO -hb2£e0103 -p2005 -hblss0103 -p2CC6 -f/test/data/prov.pay - 
nlOOOO -il 



case 11 J nd 
t!/bin/ksh 

rm /test/store/caselllnd.res 
touch /test/store/caselllnd.res 
/test/scripts/stnpt » /test/store/caselllnd.res 
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npt -tl -hb2fe01C3 -p2001 -hblssO103 -p2002 -f/test/data/prov.pay - 
nlOOOO -il 



easel 1 2d 
« !/bin/ksh 

rni /test/store/casell2d.res 
touch /te3t/store/ca3ell2c. res 
/test/scripts/stnpt » /tesc/store/casel !?.d . res 

npt -tC -hb2fe0104 -p2005 -hblssOIOi -o2006 -f /tes-/data/7inb.Day -n20C 
-ilOOO 



case! 1 2nd 



l!/bin/ksh 

rm /test/store/casel 12nd. res 
touch /test/3tore/casell2nd. res 
/test/scripts/stnpt » /test/3tore/casell2nc. res 

npt -tl -hb2fe0104 -p2001 -hblssOlOfl -p2002 -f /test/data/Tirb.pay -n200 
-ilOOO 



•- v : statS41 

vmstat » case54 1 v.result& 

a 

iostat » case54li.result& 
netstat » case54ln.result& 



£ case541txhigh 



#! /bin/ksh 

rm /teat/storo/case54 lend. res 
touch /test/store/case541cnd. res 
/test /scripts/slay 

/test/scripts/stnpt » /test/store/case541cnd.re3 

npt -tl -hblss0103 -p2001 -hblat0i03 -p2C02 -f/test/data/prov.pay -i65 
-nlOOOO & 

npt -tl -hbits0102 -p2003 -hbla.0102 -p2004 -f/test/data/rt .pay -i65 - 
nlOOOO & 
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statS42 

vmstat » case542v.rcsult& 
iostat » case542i.result& 
netstat » case542n.rcsult& 
case542rxhighp 
t!/bin/ksh 

nr. /test/store/case542prxr.d.res 
touch /te3t/store/case542prxnd.res 
/test/scripts/slay 

/test/scripta/stnpt » /test/store/case542prxnd. res 

npt -tl -hblat0103 -p2C01 -hblss0103 -p20C2 -f /test/data/prov.pay -i 

-nlOOOO 



case542rxhighc 
»!/bin/ksh 

rm /tesr/store/c23e542crxr.d.res 
touch /test /store/case542crxnd . res 
/teat /scripts/slay 

/test/scripcs/stnpt » /test/store/case542crxnd. res 

npt -tl -hblat0102 -p2003 -hblts01C2 -p2004 -f /test/data/rt .pay -i65 
nlOOOO 



stat543 

vmstat » case543v.rcsult& 
iostal » case543i.result& 
netstat » case543n.result& 
case543/dhighp 
#!/bin/ksh 

rm /test/store/caseSOfdp.res 
touch /test/store/caseS4 3fdp. res 
/test/scripts/slay 

/test/scripts/stnpt >> /test/3tore/caseb43;dp. re3 

npt -tl -hblat0103 -p2001 -hblrs0133 -p2002 -f/test/data/prov .pay 

-nlOOOOO 
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case543fdhighc 
f I/bin/ksh 

rm /test/store/caseSOfdc. rea 
couch /test/store/caseS43fdc. res 
/test /scripts /slay 

/test/scripts/stnpt » /test/store/case543fdc. res 

npt -tl -hblat0102 -p2C03 -hblts0102 -p2004 -f/test/data/rt.pay -i65 - 
nlOOOOO 



caseS43fdhigh 
#!/bin/ksh 

rm /test/store/case543fd.res 
couch /test/store/case543f d. res 
/test/scr ipts/slay 

/test/scripts/stnpt >> /cest/9tore/case543fd.res 
j-*. npt -tl -h.blrsC103 -p2001 -hblat01C3 -p2002 ~t /test/data/prov. pay -i65 

*7, -nlOOOOO & 

npt -tl -hblts0102 -p2003 -hblatC:02 -p2034 -f /test/data/rt .pay -i65 - 
u! nlOOOOO & 

^ npt -hb I tsO 1 02 -p200 1 -hb I atO 1 02 -p2002 -fltest/data/rt.pay -i65 » 

^ /test/storc/case543c.result & 

X caseSUl 

#!/bin/ksh 
^ rm /test/store/ca3e51Il.res 

touch /test/store/case5111 . res 
™ /teat/scripts/slay 

K /test/scripts/stnptudp » /test/store/caseSlll . res 

O npt -hblat0103 -p2001 -hblss0103 -p2002 -xO -f/test/data/rt.pay -ilOOO 

J-i -nlOOOOO 



caseS U 2 



#!/bin/ksh 

rm /test/store/case5112.res 
touch /test/store/caseSlI 2 . res 
/test /scripts /slay 

/test/scripts/stnptudp » /cest/store/c3se5112 . res 

npt -hblat0103 -p2001 -hblss0103 -p2002 -cO -f /test/data/rt. pay -ilOOO 
-nlOOOOO 



caseSlH 
*!/bin/ksh 
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rm /tes t/store/case5121 . res 
touch /test/store/case5121 . res 
/test/scrlpts/slay 

/tesr/scripts/stnptudp » /test/store/case5121 . res 

npt -hblss0103 -p2001 -hblrs01C3 -o2C02 -rO -f /test/data/rt .pay -ilOOO 
-nlOOOOO 



case5122 
0 !/bin/ksh 

rm /test/store/case5122 . res 
couch /test /store/ case 5 L 22 . res 
/test/scripts /slay 

/test/scripts/stnptcdp » /test/store/case5I22. res 

npt -hblss0103 -p2001 -hblrs0103 -p2C02 -rO -f /test/data/rt .pay -ilOOO 
-nlOOOOO 



case513l 

"\ 

.A #!/bin/ksh 

~ rm /test/store/case5131 . res 

r", touch /test/store/case5131.res 

Jf /test/scripts/slay 

jf /test/scripts/stnptudp » /test/store/case5131 . res 

W npt -hblss0103 -p2001 -hblrsC103 -p2002 -rO -f/test/data/rt.pay -ilOOO 

£ -nlOOOOO 

Q 

3 caseSin 

T 

2 #!/bin/ksh 

rm /test/3tore/case5132. res 
C? touch /tGst/3tore/caseS132. res 

H /test/scripts/alay 

/test/scripts/stnptudp » /test/stcre/case5132 . res 

npt -hblrs0103 -p2001 -hblrs0103 -p2002 -rO -f/test/data/rt.pay -ilOOO 
-nlOOOOO 



case5141 
#!/bin/ksh 

rm /test/store/case514I . res 
touch /test/store/case514 1 . res 
/test/3cript3/slay 

/test/scripts/stnptudp » /test/3tore/ca3e5141 .res 

npt -hblcs0103 -p2001 -hblss0103 -p2002 -rO -f/test/data/rt.pay -ilOOO 
-nlOOOOO 
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case5i42 
# !/bin/ksh 

rm /test/store/case5142 . res 
touch /test/store/case5142 . res 
/test/scripts/slay 

/test/scripts/stnptudp » /test/store/case5142 . res 

npt -hblcs0103 -p2001 -hblssC103 -p2C02 -rO -f/test/data/rt.pay -11000 
-nIOOOOO 



caseS2ll 

I !/bin/ksh 

rm /test/store/case5211.res 
touch /test/store/case5211 - res 
/test/scripts /slay 

/test/scripts/stnptudp » /test/store/case5211 . res 

npt -hblat0103 -p2001 -hbls30103 -p2C02 -rO -f /test/data/rt.pay -11000 
-nIOOOOO 



caseS2I2 
I !/bin/ksh 

rm /te3t/store/caae5212. res 
touch /test/store/case5212 . res 
/test /scripts/slay 

/test/scripts/stnptudp » /test/store/casdt>212 . res 

npt -hblat0103 -p2001 -hblss0103 -p2C02 -rO -f /test/da-a/rt .pay -ilOOO 
-nIOOOOO 

npt -hblss0103 -p2001 -hbirs0103 -p2C02 -rO -f /test/data/rt .pay -ilOOO 
» /test/store/case5221 .result £ 



case5221 
l!/bin/ksh 

rm /test/store/case5221.res 
touch /test/store/case5221 . res 
/test /scripts /slay 

/test/scripts/stnptudp » /test/store/case5221 .res 

npt -hblss0103 -p2001 -hblrs0103 -p2002 -rO -f/teat/data/rt .pay -ilOOO 
-nIOOOOO & 

npt -hblss0103 -p20Cl -hblrs0103 -p2002 -rO -t/tcst/dat.a/rt .pay -ilOOO 

-nIOOOOO L 

case5222 

#!/bin/ksh 

rm /test/store/case5222 . res 
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touch /test/store/case5222 . res 
/ test /scripts/a lay 

/test/scripts/stnptudp » /test/store/case5222.res 

npt -hblss0103 -p*2001* -hblrs0103 -p2C02 -rO -f /test/data/rt . pay -11000 
-nlOOOOO 4 



case5231 
#l/bin/kah 

rrr. /test/store/case5231 . res 
touch /test/store/ca3e5231 -res 
/test/scripts/slay 

/test/scripts/stnptudp » /test/store/caseS231 . res 

npt -hblatOL03 -p2001 -hblss0103 -p2002 -rO -f /test/data/rt .pay -ilOOO 
-nlOOOOO 4 



case5232 
#!/bin/ksh 

rm /test/store/case5232.res 
touch /test/store/case5232 . res 
/test /scripts/slay 

/test/acripts/stnptudp » /test/store/case5232 . res 

npt -hblat0103 -p2001 -hblss0103 -p2002 -rO -f /test/data/rt. pay -iiOOO 
-nlOOOOO 6 



case5241 
#!/bin/ksh 

rm /test/store/case5241.res 
touch /test/3tore/case5241.rea 
/test /scripts /slay 

/test/3cript3/stnptudp » /test/store/case524 1 . res 

npt -hblcs0103 -p2001 -hblss0103 -p2002 -rO -f /tcst/data/rt.pay -ilOOO 
-nlOOOOO t 



caseS242 
l!/bin/ksh 

rm /test/store/case5242 . res 
touch /test/store/case5242 . res 
/test/scripts /slay 

/test/scripts/stnptudp » /te3t/store/case5242 . res 

npt -hblcs0103 -p2001 -hblss0103 -p2002 -rO -f /test/data/rt. pay -ilOOO 
-nlOOOOO & 
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adhocjcase 



npt -tl -hb2feOi03 -p2001 -hblcsOl -p20O2 -f /test/data/rt.pay -n50 
ilOOQO >> /test/store/cas65ad'noc. res 

cs_adhoc_high_Iaad 



»!/bin/ksh 

su -c /usr/sbin/netstat -z 
rm /test/store/cs_adhcc_biqh_Ioad.re* 

/test/scripts/stnpc » /test/store/cs_adhoc_high_ioad. res 
npt -tl -hb2gd0101 -p2C02 -hblcsOlOl -p2C02 -f/test/cata/prov.pay - 
n20000 -ii 

/usr/sbin/netstat -s » /test/store/csnetsta- . res 
test _paths 



#! /bin/lcsh 

# scriot to test paths to each test server 
# 

HOSTNAME" ' hostname * 

system! 11-blssOl 

systecn[2)=blss0103 

3y3ten[3)«blss0104 

systen>[4]»blgd01 

systera[5]-blgd0101 

system[6]=blgd0102 

sy3tem[7]-blat01 

system[6]-blat0102 

systex[9)=blat0103 

systemtlOJ-bltsOl 

systemllli-bltsOlOl 

system{12]=blts0102 

system[13] =blcs01 

system[i4] -blcsOlOl 

systBm[15]-b2fe01 

3y3tem[161-b2fe0103 

system[17]-b2fe0104 

systemtl8]-b2gd01 

system[19]=b2gd0101 

3ystem[20)«b2gdOlO2 

rm -f test paths. leg 

touch test_paths.log 

echo "test paths from " $ HOST NAME 

echo "test path3 from " SHOSTNAMS » test_paths.log 

integer cnt=l 

while [ cnt -le S) #system(M } ] 
do 
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if (ping -c2 ${system[cntl I » /oev/nuli) 
then 

echo "reached " ${system[cnt] } 
else 

echo $ Isystem(cnt) ■ " unreachable" 

fi 

cnt=cnt+l 
done 



trace j)aths 
I! /bin/ksh 

I script to test paths to each test server 
« 

H0STNAME= * hostname * 
DATE- "date' 

FiLE='echo "/test/store/trace_"$HOSTNAME". leg" ' 

system[l]=blss01 

system[2] =blss0103 
^ sygtem[3]-blss0104 
^ system(4] -blgdOl 

vj system(5]=blgd0101 
t$ 3ystem[6]=blgd0102 
V.i system! 7 ]=blat01 

system! B]=blat0102 
fr) systemO] =blat01G3 

system! 10] -bltsOl 
£ system [ll]=b:tsOI 01 

M system(12]-bltsO102 
_! 3ystem[l3]-blcs0l 
J« systemlUJ-blcsOlOl 
S"i system( 15] =b2fe01 

O system 1 1 6] =b2fe0 103 

{£ system! 17] «b2feO104 

system! 3 8] =b2gd01 

system! 19] -b2gd0101 

3ystem!2O]-b2gdO102 

echo "trace paths from" SHOSTNAME "on" $DATE > SFILE 
echo » SFILE 

echo " Start trace on" $HOSTNAKE " " 

integer cnt-I 

while t cnt -le $Hsystem[*] } ] 
do 

echo "trace to " S (systen[cnt] } » 5 FILE 
/usr/sbin/traceroute -m 4 -w 2 $ { systexf cnt ] i » STILE 

echo " " » SFILE 

cnt=cnt+l 
done 
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What is claimed is: 9. The system according to claim 6, wherein said test tool 

1. A system for validating a telecommunications call includes mechanism for monitoring failover times for a 
processing network comprising: single component failure in said call processing network, 

a call processing network including a variety of applica- said measuring mechanism including measuring response 

tion servers and network devices for simulating ban- 5 lime before during and after failover under constant traffic 

dling of call processing traffic along first segregated loading conditions. 

routes comprising one or more subnets between asso- 10- The system according to claim 9, wherein said test 

ciated network devices, and handling of call provision- tool includes mechanism for measuring failback times when 

ing traffic along second segregated routes comprising a failed component is recovered. 

one or more subnets; said first and second segregated 10 11. The system according to claim 10, wherein said 

routes segregated according to call traffic latency failover monitor mechanism monitors failover times when 

requirements, power is removed from a redundant high-speed network 

and test tool capable of communicating test information device linked to an application server, 

packets along selected segregated routes in said call u - ^ svstem according to claim 10, wherein said 

processing network- and failover monitor mechanism monitors failover times when 

mechanism for measuring round trip latencies of commu- 15 an ^cation server interface to a redundant high-speed 

nicated packets along said selected segregated routes, network device is disconnected. 

whereby internetwork and intranetwork latency and , j 3 - ^ svstem according to claim 11, wherein said 

subnet integrity for simulated packet traffic is verified. fadover momtor mechanism monitors fallback times when 

2. The system according to claim 1, wherein said test tool , n f°^ e [ 15 restored to a redundant h.gh-speed network device 
is capable of communicating test packets at traffic load "r*ed to an apphcaUon server. 

levels of varying severity across said segregated routes, said , ^ svstem acc ° rd ">g to claim 12, wherein sari 

test tool generating test scripts for generating and commu- failover monitor mechanism monitors fallback times when 

fc nicating packets along selected segregated routes. aD ^P^tion server interface to a redundant high-speed 

3. The system according to claim 1, wherein said mecha- „ network device is reconnected. 

nism for measuring round trip latencies includes mechanism 15 A method for valldatul g a telecommunications call 
for applying time stamp information for packets entering a processing network comprising the steps of: 
call processing network path during validation test and for interconnecting a variety of application servers and net- 
comparing timestamps of returned packets to determine the work d evices for simulating a call processing network 
length of a round trip path. 30 capable of handling call processing traffic along first 
~ 4. The system according to claim 1, further comprising segregated routes comprising one or more subnets 
interface for enabling packets to enter said call processing between associated network devices, and handling of 
network, said interface including an IP socket interface. caU provisioning traffic along second segregated routes 

5. The system according to claim 4, wherein said test comprising one or more subnets; said first and second 
information packets include TCP and UDP packets. 35 segregated routes segregated according to call traffic 

6. The system according to claim 2, wherein said call latency requirements, 

processing network comprises: communicating test information packets along selected 

a first local area network (LAN) including one or more segregated routes in said call processing network; and 

network devices including a first redundant high-speed measuring round trip latencies of communicated packets 

network device dedicated for handling call traffic pro- 40 along said selected segregated routes, whereby inter- 

cessing packets; network and intranetwork latency and subnet integrity 

second LAN including one or more network devices for simulated packet traffic is verified. 

including a second redundant high-speed network 16 ^ method according to claim 15, wherein said 

device dedicated for handling call provisioning traffic communicating of test packets includes implementing test 

packets; and 45 s^pts f° r generating and communicating packets along 

a wide area network (WAN) including one or more selccled routes, said generating step including 

network devices for handling traffic destined to a generating packet traffic load levels of varying severity 

second call processing network from said call process- aC! ^i aid routes. . 

ing network, said WAN including a router device and a e 11 ■ ^ method accordm S to clai ™ 16 > wherein said step 

permanent virtual connection (PVC) established for 50 of measuru, g rou nd trip latencies includes: 

communicating packets to a receiving device at said a Pplymg time stamp information for packets entering a 

second call processing network, said segregated routes ^ n processing network path during validation test; 

including one or more of: call processing routes and * 

between one or more subnets, call processing routes comparing timestamps of returned packets to determine 

between said first and second LAN, and call processing 55 tne length of a round trip path. 

routes across said WAN via a selected PVC. 18- The method according to claim 15, further comprising 

7. The system according to claim 6, wherein said test tool providing an interface for enabling packets to enter said call 
executes scripts for providing worst-case traffic loading for processing network, said interface including an IP socket 
said router and PVC by providing simultaneous real-time, interface. 

provisioning and statistics packet traffic across said PVC and 60 1**. The method according to claim 16, wherein said 

monitoring packet latency. interconnecting includes: 

S. The system according to claim 6, wherein said test tool providing a first local area network (LAN) including one 

includes mechanism for monitoring effect of two redundant or more network devices including a first redundant 

high-speed network device interface connections receiving high-speed network device dedicated for handling call 

packets from a single application server resource in said call 65 traffic processing packets; 

processing network, said monitoring mechanism including providing a second LAN including one or more network 

measuring CPU utilization of said server resource. devices including a second redundant high-speed net- 
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work device dedicated for handling call provisioning 
traffic packets; 

providing a wide area network (WAN) including one or 
more network devices for handling traffic destined to a 
second call processing network from said call process- 
ing network via a router device; and, 

establishing and a permanent virtual connection (PVC) 
for communicating packets to a receiving device at said 
second call processing network, wherein said segre- 
gated routes includes one or more of: call processing 
routes between one or more subnets, call processing 
routes between said first and second LAN, and call 
processing routes across said WAN via a selected PVC. 

20. The method according to claim 19, further including 
the step of executing scripts for providing worst -case traffic 
loading for said router and PVC by providing simultaneous 
real-time, provisioning and statistics packet traffic across 
said PVC and monitoring packet latency. 

21. The method according to claim 19, further including 
the step of monitoring effect of two redundant high-speed 
network device interface connections for receiving packets 
from a single application server resource in said call pro- 
cessing network, said monitoring mechanism including 
measuring CPU utilization of said server resource. 

22. The method according to claim 19, further including 
the step of monitoring failover times for a single component 
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failure in said call processing network, said monitoring step 
including measuring response time before during and after 
failover under constant traffic loading conditions. 

23. The method according to claim 22, further including 
5 the step of measuring fallback times when a failed compo- 
nent is recovered. 

24. The method according to claim 23, further including 
monitoring failover times when power is removed from a 

io redundant high-speed network device linked to an applica- 
tion server. 

25. The method according to claim 23, further including 
monitoring failover times when an application server inter- 
face to a redundant high-speed network device is discon- 

15 nected. 

26. The method according to claim 24, further including 
monitoring failback times when power is restored to a 
redundant high-speed network device linked to an applica- 

20 lion server. 

27. The method according to claim 25, further including 
monitoring failback times when an application server inter- 
face to a redundant high-speed network device is recon- 
nected. 

25 

* * » * » 
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